Bug 1021 - bfd links incorrectly on solaris
Summary: bfd links incorrectly on solaris
Status: REOPENED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.22
: P1 critical
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 2524 (view as bug list)
Depends on: 1031
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-17 09:41 IST by Matthias Kurz
Modified: 2014-05-28 19:42 IST (History)
6 users (show)

See Also:
Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
Build: i386-pc-solaris2.10
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Kurz 2005-06-17 09:41:56 IST
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)
Comment 1 Sunil 2005-07-09 01:07:39 IST
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.
Comment 2 Matthias Kurz 2005-07-09 03:13:00 IST
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:
...
Comment 3 Sunil 2005-07-09 06:05:51 IST
I can't build firefox with gnu binutils. It fails with the errors mentioned in
this bug.
Comment 4 Matthias Kurz 2005-07-09 11:36:23 IST
(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)
Comment 5 Sunil 2005-07-09 19:40:09 IST
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?
Comment 6 Sunil 2005-07-09 20:20:02 IST
and gcc -G always uses versioned symbols irrespective of -lc being present or
not in the command line.
Comment 7 Eric Botcazou 2005-07-09 21:35:32 IST
> 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'.
Comment 8 Eric Botcazou 2005-07-09 21:53:35 IST
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...
Comment 9 Sunil 2005-07-10 02:05:04 IST
I haven't been able to get a simple testcase for it. simplest testcase we have
is openssl mentioned in bug 1031.
Comment 10 David Lee 2005-07-12 14:54:09 IST
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
Comment 12 Matthias Kurz 2005-07-16 16:51:19 IST
(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
Comment 13 Eric Botcazou 2005-07-16 18:36:13 IST
> 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?
Comment 14 Matthias Kurz 2005-07-16 19:05:02 IST
(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)
Comment 15 Andrew Stormont 2011-09-15 21:28:27 IST
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)
Comment 16 Andrew Stormont 2011-09-15 22:11:34 IST
*** Bug 2524 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Stormont 2011-09-17 23:30:16 IST
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.
Comment 18 Andrew Stormont 2011-09-28 15:19:26 IST
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.
Comment 19 Jackie Rosen 2014-02-16 19:43:07 IST Comment hidden (spam)