------- Comment #1 from alex at milivojevic dot org 2006-01-11 15:30 -------
I've just installed GNU binutils and recompiled gcc
(languages=c,c++,objc,java,f95) for sparc-sun-solaris2.9 and with GNU linker
and assembler. The problem exists there too. So it is libtool script not
passing -rpath argument to the linker command (doesn't depend on which ld is
used). It's kind of strange, sometimes libtool will pass the correct option to
the link command, sometimes it won't. Also, for some targets, the Makefile
doesn't seem to use libtool to create them (invokes link command directly).
Also, when creating shared libraries, if the library depends on another shared
library, I found that sometimes I need RPATH set in the shared library as well
(at least when using Sun ld). I'm not yet completely sure, but it seems that
if liba.so depends on libb.so the dynamic linker will be able to find libb.so
only if exectubale directly depends on both liba.so and libb.so. If executable
(with correct RPATH tag pointing to both liba.so and libb.so) depends only on
liba.so, the dynamic linker will fail to find libb.so. I had this problem
(when using Sun ld) with several programs that depended on libraries that in
turn depended on libgcc_s.so. Relinking the library to include RPATH tag to
where libgcc_s.so is, solved the problem. However it was kind of annoying to
have to manually fix this after almost every single library I built.
As I said, this seems to be the problem when using Sun ld. Comparing "dump -Lv
f951" outputs from excutables created by Sun and Gnu ld, the one created by Sun
ld depends only on libgmp and libc. The one created by Gnu ld depends on
libgmp, libc and libgcc_s. Looks like Sun ld will include NEEDED tags only for
libs the exectable directly depends on. Gnu ld will include NEEDED tags for
libs the executable indirectly depends on too (the libgmp depends on libgcc_s).
Because of this Sun ld behaviour, when creating shared libraries on Sun
Solaris systems, the -R or --rpath (depending which linker is used) should be
used regardless of which linker is used (since the user might mix and match
libs created by both linkers).
BTW, one difference between GNU ld and Sun ld I noticed was that Sun ld will
set both RPATH and RUNPATH tags. The GNU ld will set only RPATH. It doesn't
seem to make any difference during runtime.
Couple of examples from the last GCC build I made.
>From the build log, it doesn't seem libtool was used to create f951 (Makefile
used xgcc directly). The resulting binary is missing RPATH.
$ ldd f951
libgmp.so.3 => (file not found)
libc.so.1 => /usr/lib/libc.so.1
libgcc_s.so.1 => (file not found)
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1
$ dump -Lv f951
f951:
**** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag Value
[1] NEEDED libgmp.so.3
[2] NEEDED libc.so.1
[3] NEEDED libgcc_s.so.1
[4] INIT 0x12154
[5] FINI 0x384500
[6] HASH 0x100e8
[7] STRTAB 0x110a8
[8] SYMTAB 0x105b8
[9] STRSZ 0x6fb
[10] SYMENT 0x10
[11] DEBUG 0
[12] PLTGOT 0x3f0f60
[13] PLTSZ 0x714
[14] PLTREL 0x7
[15] JMPREL 0x11a40
[16] RELA 0x119a4
[17] RELASZ 0x7b0
[18] RELAENT 0xc
[19] VERNEED 0x11904
[20] VERNEEDNUM 0x2
[21] 1879048176
Another example. The libstdc++.so. It is missing RPATH, so dynamic linker
might fail to find libgcc_s.so during runtime (if executable was created using
Sun ld):
$ ldd libstdc++.so
libm.so.1 => /usr/lib/libm.so.1
libgcc_s.so.1 => (file not found)
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1
$ dump -Lv libstdc++.so
libstdc++.so:
**** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag Value
[1] NEEDED libm.so.1
[2] NEEDED libgcc_s.so.1
[3] NEEDED libc.so.1
[4] SONAME libstdc++.so.6
[5] INIT 0x3e9d0
[6] FINI 0xbd4c0
[7] HASH 0x94
[8] STRTAB 0x1168c
[9] SYMTAB 0x44ec
[10] STRSZ 0x21cee
[11] SYMENT 0x10
[12] PLTGOT 0xe1ee4
[13] PLTSZ 0x1950
[14] PLTREL 0x7
[15] JMPREL 0x3d080
[16] RELA 0x34fe0
[17] RELASZ 0x99f0
[18] RELAENT 0xc
[19] VERDEF 0x34db0
[20] VERDEFNUM 0xa
[21] VERNEED 0x34f00
[22] VERNEEDNUM 0x3
[23] 1879048176
[24] RELACOUNT 0x32d
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725
