[Bug target/25725] New: libtool -rpath works only for GNU ld, not for Sun ld

[Bug target/25725] New: libtool -rpath works only for GNU ld, not for Sun ld

[alex at milivojevic dot org]

Libtool is always invoked with -rpath /prefix/lib/sparcv9 option.  When using
Sun ld (/usr/ccs/bin/ld), the option should be -R/prefix/lib/sparcv9.  This
results in libraries and some executables not being able to find libraries they
depend on during runtime.  It is possible that sparc-sun-* target is also
affected (not tested).

Examples of libraries and executables that are affected: f951, libgfortran.so,
libobjc.so, libgcj.so, libffi.so.  Possibly more.

Not sure if libtool was supposed to pass -rpath as -R to actual link command
(it didn't), or if libtool should get -R instead of -rpath when Sun ld is used.


-- 
           Summary: libtool -rpath works only for GNU ld, not for Sun ld
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: alex at milivojevic dot org
 GCC build triplet: sparc64-sun-solaris2.9
  GCC host triplet: sparc64-sun-solaris2.9
GCC target triplet: sparc64-sun-solaris2.9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725

[Bug target/25725] libtool -rpath works only for GNU ld, not for Sun ld

[alex at milivojevic dot org]

------- 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

[Bug target/25725] libtool -rpath works only for GNU ld, not for Sun ld

[alex at milivojevic dot org]

------- Comment #2 from alex at milivojevic dot org  2006-01-24 15:35 -------
As a temporary workaround, I was thinking about changing Makefile.am files, and
regenerating Makefile.in so that they include both -rpath and -R when invoking
libtool (would work for me).  Looking at files, only boehm-gc/Makefile.am and
libjava/Makefile.am have '-rpath' inthere.  What to do with the rest of them? 
What do I need to change so that when automake is run I get Makefile.in files
with both -rpath and -R?

There's couple of Makefile.in files that seem not to be generated by automake
(for example, libobjc/Makefile.in), I guess I can edit them directly.

There's also gcc/fortran, that doesn't have Makefile of its own.  There's only
Make-lang.in, and it doesn't use libtool.  Hmmm...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725