Closed Bug 324283 Opened 19 years ago Closed 10 years ago

Inconsistent syntax of --with-system-FEATURE configure arguments

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: glennrp+bmo, Assigned: glennrp+bmo)

Details

Attachments

(1 file, 1 obsolete file)

v2, add --with-jpeg-prefix and --with-jpeg-exec-prefix to configure
5.77 KB, patch
Details | Diff | Splinter Review 
This is a spinoff of bug #323977.

The new "--with-system-nss" "--with-system-nspr" configure options don't
accept the "[=PFX]" option that is available when configuring other libraries
such as jpeg, zlib, and png.  This parameter is useful for people who are
testing on platforms where they don't have root access and therefore might
want to have the old library in its standard location coexisting with the
test version in their own user space.
That's because we already have --with-nspr-prefix & --with-nss-prefix.  The system-jpeg & system-png options do not have a corresponding set of -prefix & -exec-prefix options so they take an optional PREFIX argument.



Thanks.  It'd be nice to have consistency, though, which could be obtained by adding optional [=PFX] to nss and nspr and adding --with-LIB-prefix=PFX options for jpeg, png, and zlib. If we don't mind breaking a few people's .mozconfigure scripts we could also delete [=PFX] from the latter.
I don't actually see --with-nspr-prefix or --with-nss-prefix in configure.in on the 1.9a1 trunk.  Instead it uses nspr-config to find the nspr library.  I'm not quite sure yet how it would find my nss library.
The options aren't in the main configure.in.  They are read from build/autoconf/nspr.m4 and processed when AM_PATH_NSPR is used.  nspr-config is required to build against the system NSPR.  NSS has a similar setup with nss.m4,  AM_PATH_NSS & nss-config.  The options do show up in the `./configure --help` output.

If we were to synchronize the options, I would suggest breaking the zlib, jpeg & png checks into their own .m4 files.  I'm fairly indifferent about the [=PFX] on the --with-system options.
See bug #255408
Indeed they do show up in "configure --help", and in fact it is zlib, png, and
jpeg that are the inconsistent ones.  As a minimum, --with-jpeg-prefix=PFX should be added along with similar options for zlib and png.  Whether to keep the [=PFX] on the --with-system-LIB=PFX options for backward compatibility is debatable.
According to comments in configure.in, configure is supposed to use the existing nspr and nss libraries if it finds them.  On my FreeBSD 5.4 platform, the libraries exist in /usr/local/lib, so I would expect the default behaviour (which works) to be the same as if I include

ac_add_options --with-system-nss
ac_add_options --with-system-nspr
ac_add_options --with-nspr-prefix=/usr/local
ac_add_options --with-nss-prefix=/usr/local
ac_add_options --with-nspr-exec-prefix=/usr/local
ac_add_options --with-nss-exec-prefix=/usr/local

in my .mozconfig file.  It doesn't behave the same; instead it crashes
like this, when the options are present in .mozconfig:

libs_tier_9
nsI18nModule.cpp
nsDNSService2.cpp
In file included from nsDNSService2.h:40,
                 from nsDNSService2.cpp:38:
nsHostResolver.h:98: error: ISO C++ forbids declaration of `PRAddrInfo' with no
type
nsHostResolver.h:98: error: expected `;' before '*' token
nsHostResolver.h: In member function `PRBool nsHostRecord::HasResult() const':
nsHostResolver.h:102: error: `addr_info' undeclared (first use this function)
nsHostResolver.h:102: error: (Each undeclared identifier is reported only once f
or each function it appears in.)
nsHostResolver.h: At global scope:
nsHostResolver.h:212: error: `PRAddrInfo' has not been declared
nsHostResolver.h:212: error: ISO C++ forbids declaration of `parameter' with no
type
nsDNSService2.cpp: In member function `virtual nsresult nsDNSRecord::GetCanonica
lName(nsACString_internal&)':
nsDNSService2.cpp:98: error: 'class nsDerivedSafe<nsHostRecord>' has no member n
amed 'addr_info'
nsDNSService2.cpp:99: error: 'class nsDerivedSafe<nsHostRecord>' has no member n
amed 'addr_info'
nsDNSService2.cpp:99: error: `PR_GetCanonNameFromAddrInfo' undeclared (first use
 this function)
nsDNSService2.cpp: In member function `virtual nsresult nsDNSRecord::GetNextAddr
(PRUint16, PRNetAddr*)':
nsDNSService2.cpp:115: error: 'class nsDerivedSafe<nsHostRecord>' has no member
named 'addr_info'
nsDNSService2.cpp:116: error: 'class nsDerivedSafe<nsHostRecord>' has no member
named 'addr_info'
nsDNSService2.cpp:116: error: `PR_EnumerateAddrInfo' undeclared (first use this
function)
nsDNSService2.cpp: In member function `PRUint16 nsDNSService::GetAFForLookup(con
st nsACString_internal&)':
nsDNSService2.cpp:537: error: `PR_AF_UNSPEC' undeclared (first use this function
)
gmake[6]: *** [nsDNSService2.o] Error 1
gmake[5]: *** [libs] Error 2
gmake[4]: *** [libs] Error 2
gmake[3]: *** [libs_tier_9] Error 2
gmake[2]: *** [tier_9] Error 2
gmake[1]: *** [default] Error 2
gmake: *** [build] Error 2

gcc -v:
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728

Try starting with a clean build.  If the build can't find the nspr headers, then it should die long before it ever gets to netwerk/dns/src .  And without at least the compile line, I have no idea which include paths the build is using.  
It was a clean build.  Without the options, it succeeds.  With them, it fails.
Sorry, I was using "gmake -s ..." to cut down on the noise.  Rerunning without the "-s" gives this:

nsIDNService.cpp
nsDNSService2.cpp
c++ -o nsDNSService2.o -c  -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD5\" -DOSARCH
=\"FreeBSD\" -DBUILD_ID=0000000000 -DIMPL_NS_NET -I./../../base/src  -I../../../
dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -
I../../../dist/include/unicharutil -I../../../dist/include/necko -I../../../dist
/include -I/usr/local/include/nspr    -I../../../dist/sdk/include -I/usr/X11R6/i
nclude   -fPIC  -I/usr/X11R6/include  -I/usr/X11R6/include -fno-rtti -fno-except
ions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynt
h -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-
wchar -pipe  -DNDEBUG -DTRIMMED -O  -I/usr/X11R6/include  -I/usr/X11R6/include -
DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsDNSService2.p
p nsDNSService2.cpp
In file included from nsDNSService2.h:40,
                 from nsDNSService2.cpp:38:
nsHostResolver.h:98: error: ISO C++ forbids declaration of `PRAddrInfo' with no
type
nsHostResolver.h:98: error: expected `;' before '*' token
nsHostResolver.h: In member function `PRBool nsHostRecord::HasResult() const':
nsHostResolver.h:102: error: `addr_info' undeclared (first use this function)
nsHostResolver.h:102: error: (Each undeclared identifier is reported only once f
or each function it appears in.)
nsHostResolver.h: At global scope:
nsHostResolver.h:212: error: `PRAddrInfo' has not been declared
nsHostResolver.h:212: error: ISO C++ forbids declaration of `parameter' with no
type
nsDNSService2.cpp: In member function `virtual nsresult nsDNSRecord::GetCanonica
lName(nsACString_internal&)':
nsDNSService2.cpp:98: error: 'class nsDerivedSafe<nsHostRecord>' has no member n
amed 'addr_info'
nsDNSService2.cpp:99: error: 'class nsDerivedSafe<nsHostRecord>' has no member n
amed 'addr_info'
nsDNSService2.cpp:99: error: `PR_GetCanonNameFromAddrInfo' undeclared (first use
 this function)
nsDNSService2.cpp: In member function `virtual nsresult nsDNSRecord::GetNextAddr
(PRUint16, PRNetAddr*)':
nsDNSService2.cpp:115: error: 'class nsDerivedSafe<nsHostRecord>' has no member
named 'addr_info'
nsDNSService2.cpp:116: error: 'class nsDerivedSafe<nsHostRecord>' has no member
named 'addr_info'
nsDNSService2.cpp:116: error: `PR_EnumerateAddrInfo' undeclared (first use this
function)
nsDNSService2.cpp: In member function `PRUint16 nsDNSService::GetAFForLookup(con
st nsACString_internal&)':
nsDNSService2.cpp:537: error: `PR_AF_UNSPEC' undeclared (first use this function
)
gmake[6]: *** [nsDNSService2.o] Error 1
gmake[6]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la/netwerk/dns/src'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la/netwerk/dns'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la/netwerk'
gmake[3]: *** [libs_tier_9] Error 2
gmake[3]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la'
gmake[2]: *** [tier_9] Error 2
gmake[2]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la'
gmake[1]: *** [default] Error 2
gmake[1]: Leaving directory `/scratch/glennrp/Mozilla/Mozilla-1.9a1-060121/mozil
la'
gmake: *** [build] Error 2
More info:

$ ls -l /usr/local/include/nspr
total 474
drwxr-xr-x  2 root  wheel   1536 Jun 11  2005 md
-rw-r--r--  1 root  wheel   2276 Jun 20  2000 nspr.h
drwxr-xr-x  2 root  wheel    512 Jun 11  2005 obsolete
-rw-r--r--  1 root  wheel   7651 Jun 20  2000 plarena.h
-rw-r--r--  1 root  wheel   3683 Jun 20  2000 plarenas.h
-rw-r--r--  1 root  wheel   3750 Jun 20  2000 plbase64.h
-rw-r--r--  1 root  wheel   2140 Jun 20  2000 plerror.h
-rw-r--r--  1 root  wheel   2510 Jun 20  2000 plgetopt.h
-rw-r--r--  1 root  wheel   6331 Aug 21  2000 plhash.h
-rw-r--r--  1 root  wheel   3517 Jun 20  2000 plresolv.h
-rw-r--r--  1 root  wheel  14766 Oct 31  2001 plstr.h
-rw-r--r--  1 root  wheel   4429 Jun 20  2000 pratom.h
-rw-r--r--  1 root  wheel   3825 Jun 20  2000 prbit.h
-rw-r--r--  1 root  wheel   3654 Jun 20  2000 prclist.h
-rw-r--r--  1 root  wheel   3404 May  8  2001 prcmon.h
-rw-r--r--  1 root  wheel  16465 Jan  3  2003 prcountr.h
-rw-r--r--  1 root  wheel   9739 Apr  3  2005 prcpucfg.h
-rw-r--r--  1 root  wheel   4853 Jun 20  2000 prcvar.h
-rw-r--r--  1 root  wheel   3046 Jun 20  2000 prdtoa.h
-rw-r--r--  1 root  wheel   5851 Aug 30  2000 prenv.h
-rw-r--r--  1 root  wheel   9408 Jan 16  2003 prerr.h
-rw-r--r--  1 root  wheel  12552 Jun 20  2000 prerror.h
-rw-r--r--  1 root  wheel   3904 Jan 26  2002 prinet.h
-rw-r--r--  1 root  wheel   7735 Nov 24  2003 prinit.h
-rw-r--r--  1 root  wheel   6484 Jun 20  2000 prinrval.h
-rw-r--r--  1 root  wheel  77442 Nov 26  2002 prio.h
-rw-r--r--  1 root  wheel   3899 Aug 30  2000 pripcsem.h
drwxr-xr-x  2 root  wheel    512 Jun 11  2005 private
-rw-r--r--  1 root  wheel   8997 Jan 16  2003 prlink.h
-rw-r--r--  1 root  wheel   4273 Jun 20  2000 prlock.h
-rw-r--r--  1 root  wheel   8351 Dec 26  2001 prlog.h
-rw-r--r--  1 root  wheel  13774 Mar  3  2003 prlong.h
-rw-r--r--  1 root  wheel   6010 Jun 20  2000 prmem.h
-rw-r--r--  1 root  wheel   3974 Jun 20  2000 prmon.h
-rw-r--r--  1 root  wheel  17527 Jun 20  2000 prmwait.h
-rw-r--r--  1 root  wheel  16694 Jun 20  2000 prnetdb.h
-rw-r--r--  1 root  wheel   5981 Jan  7  2003 prolock.h
-rw-r--r--  1 root  wheel   3707 Jun 20  2000 prpdce.h
-rw-r--r--  1 root  wheel   5748 Jun 20  2000 prprf.h
-rw-r--r--  1 root  wheel   3566 Jun 20  2000 prproces.h
-rw-r--r--  1 root  wheel   3720 Aug 30  2000 prrng.h
-rw-r--r--  1 root  wheel   4097 Jun 20  2000 prrwlock.h
-rw-r--r--  1 root  wheel   9828 Aug 30  2000 prshm.h
-rw-r--r--  1 root  wheel   8425 Aug 30  2000 prshma.h
-rw-r--r--  1 root  wheel   3377 Apr  3  2003 prsystem.h
-rw-r--r--  1 root  wheel  10549 Jul 10  2002 prthread.h
-rw-r--r--  1 root  wheel  11437 May  8  2001 prtime.h
-rw-r--r--  1 root  wheel   3576 Aug 30  2000 prtpool.h
-rw-r--r--  1 root  wheel  23692 Jan  3  2003 prtrace.h
-rw-r--r--  1 root  wheel  18611 Jun 25  2003 prtypes.h
-rwxr-xr-x  1 root  wheel   4818 Jun 20  2000 prvrsion.h
-rw-r--r--  1 root  wheel   7268 Dec 11  2002 prwin16.h
The build is using -I/usr/local/include/nspr so the build setup is correct.  What version of NSPR do you have installed on the system?  Check PR_VERSION in prinit.h .

#define PR_VERSION  "4.4.1"
Glenn, NSPR 4.4.1 is too old for the current Mozilla.
The missing PRAddrInfo type and PR_AF_UNSPEC macro were
added in NSPR 4.5 (bug 211501).  The current Mozilla
trunk (Mozilla 1.9 alpha) is building with NSPR 4.7 Beta.
Since NSPR 4.7 hasn't been released, you should require
NSPR 4.6 or later.

Right, and that brings me back to the beginning of the discussion, where I want to use a different system nspr library than the one in /usr/local/lib.  I know how to do that now, thanks to comment #1.  There is still a bug lurking here, though, because after configure rejects the existing system libnspr4.so, seamonkey ends up using it anyhow, according to ldd.  That's probably because there are other good libraries in /usr/local/lib.  BTW shouldn't the so-number have been bumped if the library is not compatible with the previous version?
configure should require 4.6 or later, then.  But it checks for 4.0.0
or later:

checking for nspr-config... /usr/local/bin/nspr-config
checking for NSPR - version >= 4.0.0 (skipping)... yes
There are 3 issues here, all of them historical:
1) We only check for NSPR 4.0.0.  No one has really been tracking when the NSPR dependencies get bumped since we default to building against the in-tree version of NSPR.  This should be an easy fix.

2) Mozilla does not use rpath by default for reasons recently discussed in bug 304655.  So even if you build against NSPR in a different path, you need to set LD_LIBRARY_PATH so that the proper version is picked up at runtime.

2) NSPR & other Mozilla libraries do not contain soversion numbers (bug 53727).  That contributes to the problem of the wrong NSPR libs being loaded at runtime.



On FreeBSD the linking command does include --rpath:

c++ -o seamonkey-bin -I/usr/X11R6/include  -I/usr/X11R6/include -fno-rtti -fno-e
xceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -
Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fs
hort-wchar -pipe  -DNDEBUG -DTRIMMED -O -DWIDGET_DLL=\"libwidget_gtk2.so\" -DGFX
WIN_DLL=\"libgfx_gtk2.so\" -DXTHREADS -DXUSE_MTSAFE_API -I/usr/local/include/atk
-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R
6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X
11R6/include/pango-1.0 -I/usr/local/include/freetype2 -I/usr/local/include    ns
AppRunner.o showOSAlert.o nsSigHandlers.o nsStackFrameUnix.o nsNativeAppSupportG
tk.o nsNativeAppSupportBase.o   -pthread    -L../../dist/bin -L../../dist/lib
 ../../widget/src/xremoteclient/libxremote_client_s.a -L../../dist/bin -lxpcom -
lxpcom_core -L../../dist/bin -lmozjs -L../../dist/lib -lplds4 -lplc4 -lnspr4 -pt
hread  -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib -L/usr/X11R6/lib -lgtk-x1
1-2.0 -latk-1.0 -lgdk-x11-2.0 -lXrandr -lXi -lXinerama -lXfixes -lXcursor -lgdk_
pixbuf-2.0 -lpangoxft-1.0 -lXft -lfreetype -lz -lXrender -lXext -lfontconfig -lp
angox-1.0 -lX11 -lpango-1.0 -lm -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -liconv
 -L/usr/X11R6/lib -lX11  -lm

This means that seamonkey-bin links with the obsolete libnspr4 from
/usr/local/lib:

ldd seamonkey-bin
 ...
 libnspr4.so => /usr/local/lib/libnspr4.so (0x280f9000)
 ...

even though earlier in the configure script, a fresh (bundled) libnspr4.so
was built in  $PREFIX/lib/seamonkey-1.5a:
-rwxr-xr-x  1 glennrp  wheel  192328 Jan 22 05:35 libnspr4.so

Maybe the --rpath should point to the bundled libraries before it points
to /usr/local/lib,
i.e., "-W1,--rpath -W1,../../dist/lib -W1,/usr/local/lib"

Asking users to notice that the wrong library is being picked up and to adjust
their LD_LIBRARY_PATH is a lot to ask.
The --rpath seems to be coming from config/autoconf.mk.
Afaict, Mozilla doesn't use --rpath internally at all.  A hack was recently added to make FreeBSD use -R$LIBRUNPATH if LIBRUNPATH is set.  I'm pretty sure --rpath is a by-product of your build environment.  At a glance, I'm going to guess that it comes from gtk2's pkconfig output.  Can you provide a complete build log including the configure output?

I don't think that asking someone who builds their own software to take note of runtime library paths is too much to ask.  End-users will not have this problem because mozilla.org bundles the libraries in question and sets LD_LIBRARY_PATH appropriately in the application wrapper scripts.

It's not just my build environment.  The "officially" ported firefox and mozilla on this system exhibit the same situation (linking to the obsolete library
in /usr/local/lib instead of the freshly-built bundled library):

$ pwd
/usr/X11R6/lib/firefox
$ ls -l *nspr*
-rwxr-xr-x  1 root  wheel  188744 Jul 29 17:12 libnspr4.so
$ ldd firefox-bin | grep nspr
        libnspr4.so => /usr/local/lib/libnspr4.so (0x281c1000)
$ ls -l /usr/local/lib/*nspr*
-rw-r--r--  1 root  wheel  298558 Apr  3  2005 /usr/local/lib/libnspr4.a
lrwxr-xr-x  1 root  wheel      13 Apr  3  2005 /usr/local/lib/libnspr4.so -> lib
nspr4.so.1
-rwxr-xr-x  1 root  wheel  228526 Apr  3  2005 /usr/local/lib/libnspr4.so.1

Incidentally I tried building with
--without-system-nspr
--without-system-nss

and got the same results.  It linked with the obsolete /usr/local/lib/libnspr4.so.1
and not with the bundled library.
Many distributions hack our build system with extra -rpath flags: this is official not recommended or supported. If that's the cause of this "bug" then it should be filed with FreeBSD and marked INVALID here.
I'm working with a pristine distribution from CVS.  It looks as though the
unfortunate --rpath is coming in via some *-config file.  freetype-config --libs,
for example, generates one.
See comment #7.  This patch also adds the commands for zlib and png.  It does not move anything to build/config; that's for another day.
I meant to say to build/autoconf (see comment #4).  It's not a bad idea but I'd rather take one step at a time.

Since the summary doesn't reflect current thinking, I'm changing it from
  The --with-system-nss|nspr options should accept [=PFX]
to
  Inconsistent syntax of --with-system-FEATURE configure arguments
Summary: The --with-system-nss|nspr options should accept [=PFX] → Inconsistent syntax of --with-system-FEATURE configure arguments
Status: NEW → ASSIGNED
Taking bug.
Assignee: nobody → glennrp
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Somewhat simplified version.
Attachment #210310 - Attachment is obsolete: true
It seems that --with-component=/path/to/component is more intuitive, and --with-system-component means to use pkg-config or some such to use the component installed in the operating system.
I guess that would mean changing all of the library pointers, not just
jpeg, zlib, and png.  More intuitive to me would be pointers directly
to the "include" and "lib" directories instead of a prefix pointing to
a higher directory that includes include and lib, e.g.,

   --with-jpeg-lib=/usr/local/lib
   --with-jpeg-include=/usr/local/include

instead of

   --with-jpeg-prefix=/usr/local
   --with-jpeg-exec-prefix=/usr/local

But there is something to be said for doing it the conventional way, which
is what the patch attempts to do.
Also, you'd still need a pointer to the desired pkg-config script.  For example,
I might have /usr/local/bin/libpng-config and $HOME/bin/libpng-config on my
computer and need a way of selecting the one I want to use.  Something like

   --with-system-libpng-config=$HOME/bin

I realize I could set $PATH so the right one will be found, but that might
mess up finding another component.
Marking INVALID as recommended in comment #22.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: