Closed Bug 203931 Opened 22 years ago Closed 21 years ago

Linking problem on Solaris with GCC and GNU binutils

Categories

(NSS :: Build, defect, P3)

Product:
NSS
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ajp+mozilla, Assigned: wtc)

References

Details

I am currently attempting to build Mozilla 1.4a on Solaris 8 with gcc 3.2.3 and the latest version of GNU binutils. We have a non-standard installing system on our machines, which requires us to explicitly use the -rpath/-R option to ld to specify libraries that need to be linked at runtime. It seems that the build works perfectly fine up until security/nss/cmd/shlibsign, at which point it seems that it is ignoring either LDFLAGS, trying to use Solaris' ld, a combination of both, or something else. Mozilla was configured with: LDFLAGS="-R/arch/beta/lib -R/arch/gnu/lib" ./configure --prefix=/arch/beta/packages/mozilla-1.4a --disable-debug --enable-optimize=-O2 --disable-tests --enable-default-toolkit=gtk2 --with-ft-prefix=/arch/beta --disable-ldap It fails with: gcc -o SunOS5.8_OPT.OBJ/mangle -O -Wall -Wno-format -fPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__ -DSOLARIS -DSOLARIS2_8 -D_SVID_GETTOD -mcpu=v8 -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -UDEBUG -DNDEBUG -I/usr/dt/include -I/usr/openwin/include -I/tmp/mozilla/dist/include -I../../../../../dist/public/nss -I../../../../../dist/private/nss -I../../../../../dist/include -I/tmp/mozilla/dist/include/nspr -I/tmp/mozilla/dist/include/dbm SunOS5.8_OPT.OBJ/mangle.o /tmp/mozilla/dist/lib/libsmime.a /tmp/mozilla/dist/lib/libssl.a /tmp/mozilla/dist/lib/libnss.a /tmp/mozilla/dist/lib/libssl.a /tmp/mozilla/dist/lib/libsectool.a /tmp/mozilla/dist/lib/libpkcs12.a /tmp/mozilla/dist/lib/libpkcs7.a /tmp/mozilla/dist/lib/libcerthi.a /tmp/mozilla/dist/lib/libpk11wrap.a /tmp/mozilla/dist/lib/libcryptohi.a /tmp/mozilla/dist/lib/libcerthi.a /tmp/mozilla/dist/lib/libnsspki.a /tmp/mozilla/dist/lib/libpk11wrap.a /tmp/mozilla/dist/lib/libsoftokn.a /tmp/mozilla/dist/lib/libcertdb.a /tmp/mozilla/dist/lib/libnsspki.a /tmp/mozilla/dist/lib/libnssdev.a /tmp/mozilla/dist/lib/libnssb.a /tmp/mozilla/dist/lib/libswfci.a /tmp/mozilla/dist/lib/libfreebl.a /tmp/mozilla/dist/lib/libsecutil.a /tmp/mozilla/dist/lib/libdbm.a -L/tmp/mozilla/dist/lib -lplc4 -lplds4 -lnspr4 -lthread -lnsl -lsocket -lposix4 -ldl -lc ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib/libplc4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libplc4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libplc4.so value=LOCL); ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib/libplds4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libplds4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libplds4.so value=LOCL); ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib/libnspr4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libnspr4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib/libnspr4.so value=LOCL); ld: warning: file libgcc_s.so.1: required by /tmp/mozilla/dist/lib/libplc4.so, not found ../../../../coreconf/nsinstall/SunOS5.8_OPT.OBJ/nsinstall -R -m 775 SunOS5.8_OPT.OBJ/mangle /tmp/mozilla/dist/bin make[4]: Leaving directory `/tmp/mozilla/security/nss/cmd/shlibsign/mangle' SunOS5.8_OPT.OBJ/shlibsign -v -i /tmp/mozilla/dist/lib/libsoftokn3.so ld.so.1: SunOS5.8_OPT.OBJ/shlibsign: fatal: libgcc_s.so.1: open failed: No such file or directory Killed make[3]: *** [/tmp/mozilla/dist/lib/libsoftokn3.chk] Error 137 make[3]: Leaving directory `/tmp/mozilla/security/nss/cmd/shlibsign' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/tmp/mozilla/security/manager' make[1]: *** [tier_95] Error 2 make[1]: Leaving directory `/tmp/mozilla' make: *** [default] Error 2
Severity: normal → major
Hardware: PC → Sun
At first glance, this looks like a dupe of bug 200179 but I'm pretty sure that NSS is not using the -rpath flags given to configure.
Assignee: mozbugs-build → wtc
Component: Build Config → Build
Product: Browser → NSS
QA Contact: granrose → wtc
Version: Trunk → 3.8
In any case, I applied the patch attached to bug 200179 and It looks like nss is not using -rpath as well as not using GNU ld, as I get the same kind of errors ("global symbol...non-global binding") when trying to use Solaris' linker instead of GNU's, when gcc was compiled with GNU binutils. In any case, I applied the patch attached to bug 200179 and still get the same problem. One thing I did notice, though - the same messages happen earlier in the nss build process, but for some reason they're not fatal. Example: rm -f SunOS5.8_OPT.OBJ/libfreebl_pure32_3.so gcc -shared -h libfreebl_pure32_3.so -Wl,-B,symbolic,-z,defs,-z,now,-z,text,-M,mapfile.Solaris -o SunOS5.8_OPT.OBJ/libfreebl_pure32_3.so SunOS5.8_OPT.OBJ/ldvector.o SunOS5.8_OPT.OBJ/prng_fips1861.o SunOS5.8_OPT.OBJ/sysrand.o SunOS5.8_OPT.OBJ/sha_fast.o SunOS5.8_OPT.OBJ/md2.o SunOS5.8_OPT.OBJ/md5.o SunOS5.8_OPT.OBJ/sha512.o SunOS5.8_OPT.OBJ/alg2268.o SunOS5.8_OPT.OBJ/arcfour.o SunOS5.8_OPT.OBJ/arcfive.o SunOS5.8_OPT.OBJ/desblapi.o SunOS5.8_OPT.OBJ/des.o SunOS5.8_OPT.OBJ/rijndael.o SunOS5.8_OPT.OBJ/aeskeywrap.o SunOS5.8_OPT.OBJ/dh.o SunOS5.8_OPT.OBJ/ec.o SunOS5.8_OPT.OBJ/GFp_ecl.o SunOS5.8_OPT.OBJ/pqg.o SunOS5.8_OPT.OBJ/dsa.o SunOS5.8_OPT.OBJ/rsa.o SunOS5.8_OPT.OBJ/shvfy.o SunOS5.8_OPT.OBJ/mpprime.o SunOS5.8_OPT.OBJ/mpmontg.o SunOS5.8_OPT.OBJ/mplogic.o SunOS5.8_OPT.OBJ/mpi.o /tmp/mozilla/dist/lib/libsecutil.a -L/tmp/mozilla/dist/lib/ -lplc4 -lplds4 -lnspr4 -lc ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib//libplc4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libplc4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libplc4.so value=LOCL); ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib//libplds4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libplds4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libplds4.so value=LOCL); ld: warning: global symbol `_DYNAMIC' has non-global binding: (file /tmp/mozilla/dist/lib//libnspr4.so value=LOCL); ld: warning: global symbol `_PROCEDURE_LINKAGE_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libnspr4.so value=LOCL); ld: warning: global symbol `_GLOBAL_OFFSET_TABLE_' has non-global binding: (file /tmp/mozilla/dist/lib//libnspr4.so value=LOCL); ld: warning: file libgcc_s.so.1: required by /tmp/mozilla/dist/lib//libplc4.so, not found chmod +x SunOS5.8_OPT.OBJ/libfreebl_pure32_3.so /tmp/mozilla/security/nss/lib/freebl/../../../coreconf/nsinstall/SunOS5.8_OPT.OBJ/nsinstall -R -m 775 SunOS5.8_OPT.OBJ/libfreebl_pure32_3.so /tmp/mozilla/dist/lib make[5]: Leaving directory `/tmp/mozilla/security/nss/lib/freebl/SunOS5.8_OPT.OBJ/SunOSpure32' Odd, no?
You should be able to work around this bug by adding /arch/beta/lib:/arch/gnu/lib to your LD_LIBRARY_PATH environment variable before you start the Mozilla build. I don't know how to fix the ld warnings about _DYNAMIC, _PROCEDURE_LINKAGE_TABLE_, and _GLOBAL_OFFSET_TABLE_ and whether they can be safely ignored.
Status: NEW → ASSIGNED
The problem is twofold - one is that Solaris' linker is being used instead of GNU ld, the one used to compile gcc; and LDFLAGS are not being preserved in the nss tree. Even if I get ld to find libgcc_*, it's still using the wrong linker on pretty much every component of nss, which is not a good thing.
In the exact same environment in which you build Mozilla 1.4a, please execute the following commands and let me know the output. % which gcc % gcc -v % gcc -print-prog-name=ld % `gcc -print-prog-name=ld` -v Is this "gcc" the compiler you want to build Mozilla 1.4a with? Is the environment variable "CC" defined? What is its value?
I'm using gcc-3.2 to build mozilla, not gcc. CC and CXX are set to gcc-3.2 and g++-3.2, respectively. (~)$ which gcc-3.2 /arch/beta/bin/gcc-3.2 (~)$ gcc-3.2 -v Reading specs from /arch/beta/packages/gcc-3.2.3/lib/gcc-lib/sparc-sun-solaris2.8/3.2.3/specs Configured with: ../configure --program-suffix=-3.2 --prefix=/arch/beta/packages/gcc-3.2.3 --with-ld=/arch/gnu/bin/ld --with-as=/arch/gnu/bin/as Thread model: posix gcc version 3.2.3 (~)$ gcc-3.2 -print-prog-name=ld /arch/gnu/bin/ld (~)$ `gcc-3.2 -print-prog-name=ld` -v GNU ld version 2.13.2.1
I think I know what the problem is (why GNU ld is not being used). I still need some information, and I'll need you to follow the instructions *exactly*: In the exact same environment in which you build Mozilla 1.4a, please execute the following commands and let me know the output. % which gcc % gcc -v % gcc -print-prog-name=ld % `gcc -print-prog-name=ld` -v
(~)$ which gcc /arch/gnu/bin/gcc (~)$ gcc -v Reading specs from /arch/gnu/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) (~)$ gcc -print-prog-name=ld /usr/ccs/bin/ld (~)$ `gcc -print-prog-name=ld` -v /usr/ccs/bin/ld: illegal option -- v usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit [-a] create an absolute file ...
Thank you for the info. The reason that the wrong linker is used by NSS is that NSS has its own independent build system (called "coreconf") and Mozilla is not passing the value of CC to NSS (bug 93206), so NSS uses "gcc" (specified in its coreconf makefiles) instead of "gcc-3.2" as the value of CC. This problem can be fixed by the patch in bug 93206. (The patch in bug 93206 hasn't been checked in because it still needs work, but it is good enough to work for you.) Please let me know if this also gets rid of the fix the ld warnings about _DYNAMIC, _PROCEDURE_LINKAGE_TABLE_, and _GLOBAL_OFFSET_TABLE_. Please post the command lines NSS uses to build "mangle" and "libfreebl_pure32_3.so". The LDFLAGS problem is more work to fix and I suggest that you work around it as I described in comment 3.
Depends on: 93206
It seems to work fine for me finally. Unfortunately, I wasn't able to catch the build log so I don't know what messages were printed.
You can rebuild just NSS as follows. 1. In your build tree, cd into the security/manager directory. 2. gmake clean 3. gmake In Step 3, redirect the standard output and standard error streams to a build log file. When it is done, open the build log file and search for "mangle" and "libfreebl_pure32_3.so". I am worried about the ld warnings about _DYNAMIC, _PROCEDURE_LINKAGE_TABLE_, so I'd like to know if they are caused by the wrong linker being used. Thanks. _GLOBAL_OFFSET_TABLE_
(/tmp/mozilla/security/manager)$ make clean make: *** No rule to make target `clean'. Stop.
Does /tmp/mozilla/security/manager/Makefile exist? Did you do something earlier (e.g., make distclean) to delete all the Makefile's in your build tree?
nope, it doesn't seem like it was ever there in the first place - I can still run make from the toplevel Mozilla tree.
Ah crap, I forgot to build with --enable-crypto this time. I'll try again.
Looks like LD_LIBRARY_PATH has no effect in nss whether set during configure or make.
You are right. I forgot that LD_LIBRARY_PATH doesn't work in Mozilla 1.4a. In order to use the LD_LIBRARY_PATH workaround you need to apply the patch in bug 200179. Sorry about that. You only need to set LD_LIBRARY_PATH during make.
nope, still not working.
If you are using Bourne shell, Korn shell,or Bash, you also need to say "export LD_LIBRARY_PATH" after you set LD_LIBRARY_PATH. Please post 1. the value of LD_LIBRARY_PATH. 2. the contents of the directories listed in LD_LIBRARY_PATH. 3. the contents of /tmp/mozilla/security/nss/cmd/shlibsign/sign.sh. 4. the build error messages.
Argh, I just realized I applied the patch wrongly, so I'll do it correctly and try again. P.S. I didn't get the linker symbol error messages, only the message about not being able to find libgcc_s.so.1.
Okay, it finally seems to work now with LD_LIBRARY_PATH. /arch/beta/bin/gcc-3.2 -o SunOS5.8_OPT.OBJ/mangle -O -Wall -Wno-format -fPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__ -DSOLARIS -DSOLARIS2_8 -D_SVID_GETTOD -mcpu=v8 -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -UDEBUG -DNDEBUG -I/usr/dt/include -I/usr/openwin/include -I/tmp/mozilla/dist/include -I../../../../../dist/public/nss -I../../../../../dist/private/nss -I../../../../../dist/include -I/tmp/mozilla/dist/include/nspr -I/tmp/mozilla/dist/include/dbm SunOS5.8_OPT.OBJ/mangle.o /tmp/mozilla/dist/lib/libsmime.a /tmp/mozilla/dist/lib/libssl.a /tmp/mozilla/dist/lib/libnss.a /tmp/mozilla/dist/lib/libssl.a /tmp/mozilla/dist/lib/libsectool.a /tmp/mozilla/dist/lib/libpkcs12.a /tmp/mozilla/dist/lib/libpkcs7.a /tmp/mozilla/dist/lib/libcerthi.a /tmp/mozilla/dist/lib/libpk11wrap.a /tmp/mozilla/dist/lib/libcryptohi.a /tmp/mozilla/dist/lib/libcerthi.a /tmp/mozilla/dist/lib/libnsspki.a /tmp/mozilla/dist/lib/libpk11wrap.a /tmp/mozilla/dist/lib/libsoftokn.a /tmp/mozilla/dist/lib/libcertdb.a /tmp/mozilla/dist/lib/libnsspki.a /tmp/mozilla/dist/lib/libnssdev.a /tmp/mozilla/dist/lib/libnssb.a /tmp/mozilla/dist/lib/libswfci.a /tmp/mozilla/dist/lib/libfreebl.a /tmp/mozilla/dist/lib/libsecutil.a /tmp/mozilla/dist/lib/libdbm.a -L/tmp/mozilla/dist/lib -lplc4 -lplds4 -lnspr4 -lthread -lnsl -lsocket -lposix4 -ldl -lc /arch/beta/bin/gcc-3.2 -shared -h libfreebl_pure32_3.so -Wl,-Bsymbolic,-z,defs,-z,now,-z,text,--version-script,mapfile.Solaris -o SunOS5.8_OPT.OBJ/libfreebl_pure32_3.so SunOS5.8_OPT.OBJ/ldvector.o SunOS5.8_OPT.OBJ/prng_fips1861.o SunOS5.8_OPT.OBJ/sysrand.o SunOS5.8_OPT.OBJ/sha_fast.o SunOS5.8_OPT.OBJ/md2.o SunOS5.8_OPT.OBJ/md5.o SunOS5.8_OPT.OBJ/sha512.o SunOS5.8_OPT.OBJ/alg2268.o SunOS5.8_OPT.OBJ/arcfour.o SunOS5.8_OPT.OBJ/arcfive.o SunOS5.8_OPT.OBJ/desblapi.o SunOS5.8_OPT.OBJ/des.o SunOS5.8_OPT.OBJ/rijndael.o SunOS5.8_OPT.OBJ/aeskeywrap.o SunOS5.8_OPT.OBJ/dh.o SunOS5.8_OPT.OBJ/ec.o SunOS5.8_OPT.OBJ/GFp_ecl.o SunOS5.8_OPT.OBJ/pqg.o SunOS5.8_OPT.OBJ/dsa.o SunOS5.8_OPT.OBJ/rsa.o SunOS5.8_OPT.OBJ/shvfy.o SunOS5.8_OPT.OBJ/mpprime.o SunOS5.8_OPT.OBJ/mpmontg.o SunOS5.8_OPT.OBJ/mplogic.o SunOS5.8_OPT.OBJ/mpi.o /tmp/mozilla/dist/lib/libsecutil.a -L/tmp/mozilla/dist/lib/ -lplc4 -lplds4 -lnspr4 -lc
Adjusted severity and priority per discussion with wtc. Change is due to finding a workaround.
Severity: major → minor
Priority: -- → P3
So, to recap for those just joining us who want to compile Mozilla with gcc and GNU ld: 1. Start with mozilla 1.4b (I assume it contains the patch in bug 200179) 2. configure as usual 3. build with 'LD_LIBRARY_PATH="<colon-separated list of paths with libraries needed for compilation, namely GTK and libgcc_s.so.1>" make [whatever make options you use]'
Yes, Mozilla 1.4b contains the patch in bug 200179. You still need to apply the patch in bug 93206 to Mozilla 1.4b if "gcc" is not the gcc you want to use.
Hi, reporter, I have build lastest mozilla with the gcc 3.4.2 (installed under my home directory) with the options you mentioned, But the files under security/nss/cmd/shlibsign are not compiled. so would you please tell me the detailed information (e.g. your configuration settings)? Thanks
(In reply to comment #25) I haven't actually tried building Mozilla myself since 1.5 or so since Sun isn't putting out a Java plugin for the new C++ ABI, so I don't really know if anything has changed.
I have built the latest mozilla with gcc-3.4.2 installed under my home directory successfully. The mangle file has passed compiling. So I think this bug doesn't exist in current mozilla.
(In reply to comment #27) If you don't have gcc installed in any of the system-wide paths, then I'll trust your judgement that this is now fixed.
Yes, actually I downloaded gcc3.4.2 source, built it and installed under my home directory (normal user). So I think this bug doesn't exist in current trunk.
(In reply to comment #29) > Yes, actually I downloaded gcc3.4.2 source, built it and installed under my home > directory (normal user). So I think this bug doesn't exist in current trunk. Well, I understood that part, but I was just making sure you didn't have any other copies of gcc/libgcc lying around on your system that the build could have used without you realizing.
yes. there is no other gcc installed on my machine. So I think this bug can be closed
Resolving as WFM unless someone knows of a specific fix for this.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.