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

Thu Dec 24 11:10:48 UTC 2009

On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote:
>       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!)
>

Unfortunately this error with libxul arises only on my i386 systems. On 
my amd64 systems (9.0-CURRENT) with allmost the same configuration and 
installed ports libxul builds fine. It seems to be a question of 
configuration or composition of other, already installed ports.

I tried to reconfigure and reinstall all ports, from which libxul is 
depending, without success. libxul is broken for me on all i386 systems.

And I can confirm that there is no xulrunner installed (yesterday 
question from Beat).

>> 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.
> :-)