From owner-freebsd-ports@FreeBSD.ORG Thu Dec 24 08:47:08 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFAE10656A8 for ; Thu, 24 Dec 2009 08:47:08 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 74AFC8FC1C for ; Thu, 24 Dec 2009 08:47:08 +0000 (UTC) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.3/8.14.3) with ESMTP id nBO8kIaH004204; Thu, 24 Dec 2009 02:46:18 -0600 (CST) Date: Thu, 24 Dec 2009 02:46:18 -0600 (CST) From: Scott Bennett Message-Id: <200912240846.nBO8kIK4004203@mp.cs.niu.edu> To: freebsd-ports@freebsd.org, Anton Shterenlikht Cc: Rainer Hurling Subject: Re: ports/141131: www/libxul does not compile any more X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 08:47:08 -0000 On Tue, 22 Dec 2009 11:46:06 +0000 Anton Shterenlikht 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 * **********************************************************************