Building mozilla under Solaris 10 fails. When g++ (3.4.4) tries to link regxpcom it bombs out with the following errors: mozilla/dist/bin/libnspr4.so: undefined reference to `fcntl@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `dlsym@SUNW_0.7' mozilla/dist/bin/libnspr4.so: undefined reference to `pthread_join@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `select@SUNW_1.2' mozilla/dist/bin/libnspr4.so: undefined reference to `rw_unlock@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `pthread_attr_destroy@SUNW_ 0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `dlerror@SUNW_0.7' .. and so on I saw similiar reports from other users (google, see also http://sourceware.org/ml/binutils/2005-06/msg00466.html). I need to build with GNU binutils because i use OpenPKG and it is the default there. (mk)
this is a very common error with binutils on solaris 10. Its stopping building of any packages(not only mozilla, but openssl, xmms, mplayer to name a few) on solaris 10. Can somebody please expedite this issue? one hint we have is that all static libraries(libc, libnsl, etc.) from solaris 9 are removed in solaris 10 and symbol versioning might have something to do with that. somehow ccs/bin/ld accounts for it and binutils ld doesn't.
Well, i can build openssl (0.9.8) and also firefox. But when i do a "elfdump .../lib/firefox/libnspr4.so", there is a message: '/opkg/lib/firefox/libnspr4.so: .note: bad sh_offset alignment' And when i do a elfdump on the libnspr4.so that is generated when i try to build mozilla, i see in the end: Note Section: .note type 0x1 namesz 0x8: 01.01^@^@^@ descsz 0: type 0x1 namesz 0x8: 01.01^@^@^@ descsz 0: type 0x1 namesz 0x8: 01.01^@^@^@ descsz 0: type 0x1 namesz 0x8: 01.01^@^@^@ descsz 0: ...
I can't build firefox with gnu binutils. It fails with the errors mentioned in this bug.
(In reply to comment #3) > I can't build firefox with gnu binutils. It fails with the errors mentioned in > this bug. Well, when it is an alignment/padding problem, it is highly dependent on the exact code, so it probably only accidently works for me for some things, currently. Is there an exact description for the linker file format somewhere, so that one can compare the GNU binutils generated file "byte by byte" with the one that is generated using the native tools ? Does OpenSolaris contain documentation and is there a description how they implemented their "versioning" ? (mk) (mk)
If I create any shared library with gcc -shared ... -lc, it includes specific versioned symbols from libc, whereas if '-lc' is not there, it thinks any version goes and includes unversioned undefined references. this automatically breaks -zdefs because now you have to have -lc but specific version symbols will be referenced and you will run into link error later. How come this bug is not yet assigned to someone, when everything about binutils is broken on solaris 10?
and gcc -G always uses versioned symbols irrespective of -lc being present or not in the command line.
> How come this bug is not yet assigned to someone, when everything about > binutils is broken on solaris 10? Only the linker is presumably broken actually. Solaris 10 ships with GCC 3.4.3 that uses GNU as: % /usr/sfw/bin/gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) % /usr/sfw/sparc-sun-solaris2.10/bin/as --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.10'.
Btw, if someone distilled a small testcase, I could try to take a look. I should already have done so because libgcj cannot be linked with the GNU linker, but working with libgcj is such a pain...
I haven't been able to get a simple testcase for it. simplest testcase we have is openssl mentioned in bug 1031.
Another test case for this Solaris-10/GNU-ld problem is in "libtool" v. 1.5.18 (current stable), in its "make check" phase, in its "mdemo2-make.test". More detail by doing: make check VERBOSE=x TESTS='mdemo-conf.test mdemo-make.test mdemo2-conf.test mdemo2-make.test mdemo2-exec.test' (that's one long line). On archive of "libtool@gnu.org", see thread "solaris 10: dlopen@SISCD_2.3". Hope that helps. -- David Lee
http://sourceware.org/ml/binutils-cvs/2005-07/msg00121.html http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html
(In reply to comment #11) > http://sourceware.org/ml/binutils-cvs/2005-07/msg00121.html > http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html > Thanks for your effords, Eric. I'm afraid, linking of mozilla under Solaris 10 x86 still fails. /opkg/bin/gcc -shared -Wl,-h,libplds4.so,-z,combreloc,-z,defs -o libplds4.so -Wl ,--version-script,./pldsmap.sun ./plarena.o ./plhash.o ./plvrsion.o -L/u/projec ts/tmp/opkg/mozilla/dist/lib -lnspr4 -lc /opkg/bin/ld: /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: open64: invalid version 23 (max 7) /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: could not read symbols: Bad v alue
> I'm afraid, linking of mozilla under Solaris 10 x86 still fails. I don't have access to x86/Solaris 10 so I can't really debug this. > /opkg/bin/gcc -shared -Wl,-h,libplds4.so,-z,combreloc,-z,defs -o libplds4.so > -Wl ,--version-script,./pldsmap.sun ./plarena.o ./plhash.o ./plvrsion.o > -L/u/projec ts/tmp/opkg/mozilla/dist/lib -lnspr4 -lc > /opkg/bin/ld: /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: open64: > invalid version 23 (max 7) > /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: could not read symbols: Bad > value Did you link libnspr4.so with the patched linker too?
(In reply to comment #13) > > I'm afraid, linking of mozilla under Solaris 10 x86 still fails. > [...] > > Did you link libnspr4.so with the patched linker too? Yes, i rebuilt every dependency (glib,gtk,freetype, etc.etc.) and mozilla itself from scratch with the patched binutils package (2.16.1). (mk)
There are two issues here. The original problem (see comment 1) mozilla/dist/bin/libnspr4.so: undefined reference to `fcntl@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `dlsym@SUNW_0.7' mozilla/dist/bin/libnspr4.so: undefined reference to `pthread_join@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `select@SUNW_1.2' mozilla/dist/bin/libnspr4.so: undefined reference to `rw_unlock@SUNW_0.9' mozilla/dist/bin/libnspr4.so: undefined reference to `pthread_attr_destroy@SUNW_ Was due to the fact that bfd ignored versions on all absolute symbols. This is fixed. The second problem (see comment 12) /opkg/bin/gcc -shared -Wl,-h,libplds4.so,-z,combreloc,-z,defs -o libplds4.so -Wl ,--version-script,./pldsmap.sun ./plarena.o ./plhash.o ./plvrsion.o -L/u/projec ts/tmp/opkg/mozilla/dist/lib -lnspr4 -lc /opkg/bin/ld: /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: open64: invalid version 23 (max 7) /u/projects/tmp/opkg/mozilla/dist/lib/libnspr4.so: could not read symbols: Bad v alue This is due the the fact that bfd gets confused and writes a duff open64 symbol to libnspr4.so which causes then next part of the build to fail. I've tried to build with and without mapfile and it makes no difference. And this is with the lastest binutils from git. Here is the output from readelf: # readelf -s ./mozilla/nsprpub/dist/bin/libnspr4.so | grep open64 536: 00000000 240 FUNC GLOBAL DEFAULT ABS open64@@NSPR_4.8.9 1352: 00000000 240 FUNC GLOBAL DEFAULT ABS open64@@SUNW_1.1 This is what it looks like on Linux: # readelf -s /usr/lib/libnspr4.so | grep open64 84: 0000000000000000 0 FUNC GLOBAL DEFAULT UND open64@GLIBC_2.2.5 (3)
*** Bug 2524 has been marked as a duplicate of this bug. ***
Some more output that might be useful. Solaris: # readelf -a ./mozilla/nsprpub/dist/lib/libnspr4.so | grep open64 0002d204 00021706 R_386_GLOB_DAT 00000000 open64 535: 00000000 240 FUNC GLOBAL DEFAULT ABS open64@@NSPR_4.8.9 1351: 00000000 240 FUNC GLOBAL DEFAULT ABS open64@@SUNW_1.1 # readelf -a /lib/libc.so | grep open64 21: 00071378 140 FUNC GLOBAL PROTECTED 15 attropen64 70: 000a56f8 57 FUNC GLOBAL PROTECTED 15 fopen64 332: 00071378 140 FUNC WEAK PROTECTED 15 _attropen64 874: 000a5978 290 FUNC GLOBAL PROTECTED 15 freopen64 950: 000bff10 240 FUNC WEAK PROTECTED 15 _open64 1062: 000bff10 240 FUNC GLOBAL PROTECTED 15 open64 364: 000a9588 53 FUNC LOCAL HIDDEN 15 __open64 5937: 00071378 140 FUNC GLOBAL PROTECTED 15 attropen64 5986: 000a56f8 57 FUNC GLOBAL PROTECTED 15 fopen64 6248: 00071378 140 FUNC WEAK PROTECTED 15 _attropen64 6790: 000a5978 290 FUNC GLOBAL PROTECTED 15 freopen64 6866: 000bff10 240 FUNC WEAK PROTECTED 15 _open64 6978: 000bff10 240 FUNC GLOBAL PROTECTED 15 open64 21: attropen64 SELF DIRECT 70: fopen64 SELF DIRECT 332: _attropen64 SELF DIRECT 874: freopen64 SELF DIRECT 950: _open64 SELF DIRECT 1062: open64 SELF DIRECT Linux: # readelf -a /usr/lib/libnspr4.so | grep open64 000000237f28 005400000006 R_X86_64_GLOB_DAT 0000000000000000 open64 + 0 84: 0000000000000000 0 FUNC GLOBAL DEFAULT UND open64@GLIBC_2.2.5 (3) # readelf -a /lib/libc.so.6 | grep open64 292: 00000000000dd490 33 FUNC GLOBAL DEFAULT 12 __open64_2@@GLIBC_2.7 533: 00000000000d8120 94 FUNC WEAK DEFAULT 12 __open64@@GLIBC_2.2.5 858: 00000000000d8120 94 FUNC WEAK DEFAULT 12 open64@@GLIBC_2.2.5 1094: 000000000006cd90 606 FUNC GLOBAL DEFAULT 12 freopen64@@GLIBC_2.2.5 1948: 0000000000068580 10 FUNC WEAK DEFAULT 12 fopen64@@GLIBC_2.2.5 At first glance it looks as if bfd is having problems with the STV_PROTECTED symbols in solaris libc and is mistakenly marking them as local and copying them into the output file.
I have $100 for anybody that can provide a patch to solve this issue. I think it should be fairly simple if you know your way around BFD.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
Great question and answer website! Thank you so much, keep it up the good deed! Please visit our sites also: https://www.bradentonrescreening.com/screen-repair--re-screening--st-petersburg-fl.html/ : https://www.bradentonrescreening.com/screen-repair--re-screening--sarasota-fl.html/ : https://www.vahomeloanmi.com/