Date: Thu, 24 Dec 2009 12:10:34 +0100 From: Rainer Hurling <rhurlin@gwdg.de> To: Scott Bennett <bennett@cs.niu.edu> Cc: Anton Shterenlikht <mexas@bristol.ac.uk>, Beat Gaetzi <beat@FreeBSD.org>, freebsd-ports@freebsd.org Subject: Re: ports/141131: www/libxul does not compile any more Message-ID: <4B334C2A.3050005@gwdg.de> In-Reply-To: <200912240846.nBO8kIK4004203@mp.cs.niu.edu> References: <200912240846.nBO8kIK4004203@mp.cs.niu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote: > On Tue, 22 Dec 2009 11:46:06 +0000 Anton Shterenlikht > <mexas@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. > :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B334C2A.3050005>