ports/141131: www/libxul does not compile any more

Thu Dec 24 08:47:08 UTC 2009

     On Tue, 22 Dec 2009 11:46:06 +0000 Anton Shterenlikht
<mexas at bristol.ac.uk> wrote:
>On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote:
>> On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote:
>> > On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote:
>> >> According to PR 141131 I see exactly the same error messages when I try
>> >> to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16:
>> >>
>> >> -----------------------------------
>> >> [..snip..]
>> >> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi
>> >> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX
>> >> -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\"
>> >> -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG
>> >> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC
>> >> -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include
>> >> -I/usr/local/include/nspr
>> >> -I/usr/ports/www/libxul/work/mozilla/dist/include
>> >> -I../../../../dist/public/nss -I../../../../dist/private/nss
>> >> -I../../../../dist/include  -Impi -Iecl  dsa.c
>> >> dsa.c: In function 'FIPS186Change_ReduceModQForDSA':
>> >> dsa.c:75: error: 'mp_int' undeclared (first use in this function)
>> >> dsa.c:75: error: (Each undeclared identifier is reported only once
>> >> dsa.c:75: error: for each function it appears in.)
>> >> dsa.c:75: error: expected ';' before 'W'
>> >> dsa.c:76: error: 'mp_err' undeclared (first use in this function)
>> >> dsa.c:76: error: expected ';' before 'err'
>> >> [..snip..]
>> >> gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1
>> >> gmake[6]: Leaving directory
>> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl'
>> >> gmake[5]: *** [libs] Fehler 2
>> >> gmake[5]: Leaving directory
>> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl'
>> >> gmake[4]: *** [libs] Fehler 2
>> >> gmake[4]: Leaving directory
>> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib'
>> >> gmake[3]: *** [libs] Fehler 2
>> >> gmake[3]: Leaving directory
>> >> `/usr/ports/www/libxul/work/mozilla/security/manager'
>> >> gmake[2]: *** [libs_tier_toolkit] Fehler 2
>> >> gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla'
>> >> gmake[1]: *** [tier_toolkit] Fehler 2
>> >> gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla'
>> >> gmake: *** [default] Fehler 2
>> >> *** Error code 1
>> >> -----------------------------------
>> >>
>> >> This happens on three different machines all running latest 9.0-CURRENT
>> >> (i386). As far as I can see there are no relevant flags set in
>> >> etc/make.conf.
>> >>
>> >> Any clues what is going wrong? I found no solution to this PR.
>> >>
>> >> Please let me know if I can provide more information or test something.
>> >
>> > I've got libxul-1.9.0.16 built fine on ia64 and sparc64.
>> > No issues, just 'portmaster -force-config -Bd libxul'.
>> >
>> 
>> Thanks for answering.
>> 
>> As I wrote before, I have this on different machines, all running newest 
>> i386-CURRENT. On another machine with amd64-CURRENT I had been able to 
>> compile libxul-1.9.0.16. Perhaps there is something wrong with my 
>> configuration? (I copied most from system to system ...)
>
># uname -srm
>FreeBSD 9.0-CURRENT i386
># pkg_info -xo libxul
>Information for libxul-1.9.0.16:
>
>Origin:
>www/libxul
>
># cd /usr/ports/www/libxul
># make showconfig
>===> The following configuration options are available for libxul-1.9.0.16:
>     JAVA=off "Enable JAVA xpcom"
>     DEBUG=off "Build a debugging image"
>     LOGGING=off "Enable additional log messages"
>     OPTIMIZED_CFLAGS=off "Enable some additional optimizations"
>===> Use 'make config' to modify these settings
># 
>
>Have you checked /etc/make.conf, /etc/src.conf?
>
     I doubt that either of those has anything to do with the problem.  An
update for libxul came through in the last two to four days that broke it.
It halted my "portmaster -a" run, so I've added -x libxul to the command for
now until another update for it comes through.  For now, though, it's broken
on 7.2-STABLE as well as on Rainer's system.
     FWIW, there have been other bad updates recently, too, although many
have been fixed by subsequent updates within a few days.  A bad pair of
updates came through a couple of days ago:  print/gutenprint and
print/gimp-gutenprint.  These have yet to be fixed.
     multimedia/gstreamer-plugins-dvd was broken by an update a while back,
three or four months, I think.  It remains unfixed today.
     Note that these problems are not execution or functional problems in
the code, but rather problems that prevent the port from completing the
updating process all the way through installation.  This sort of problem is
not a daily thing by any means, so it seems like most of the maintainers know
what they're about, for which we can all be grateful.  But it does seem to
happen a few times per month, which suggests that at least a few maintainers
don't or perhaps may lose track of a testing step or two when under pressure.
(And there certainly is a *lot* of ports to maintain!)
     
>Sorry, have no other ideas.
>
     Well, an elementary one occurs to me.  If the person committing an
update or, if applicable, the non-committer maintainer giving the update to
a committer, were actually to try *configuring, compiling, and installing*
the port involved before committing the update (or passing it to a committer),
that person could then see that it didn't actually work and could therefore
delay any "commit" operation until a version had been tested with one or
more standard port-maintenance utility (e.g., portmaster, portupgrade,
portmanager) and found to work properly.  That way no unbuildable or
uninstallable updates would ever come through on a "portsnap fetch update"
...NAAHHHH...that's just ridiculous.
Silly me.
:-)


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************