Closed Bug 203931 Opened 21 years ago Closed 20 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: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.