ld's RPATH versus gcc's

ld's RPATH versus gcc's

[Chris McCraw]

hi there,

i'm hoping you folks can shed some light on a situation i'm trying to cope
with.

environment:
solaris 2.9/ultrasparc
gcc version 3.4.3, compiled with gcc and gnu binutils (v 3.3.4/2.13.2.1)
gcc uses gnu that ld/as.
no /var/ld/ld.config (in case that matters)

in my gcc specs file extra libdirs are specified for linking in the *link
section:
	-R /lusr/lib -R /lusr/gnome2/lib

i rename the *link section removing the -R's above since i do not want
to use shared libs in there, by passing my own specs file with
	gcc -specs /u/fool/specs

and verify that gcc is applying my change with gcc -v:

  Reading specs from /path/to/gcc3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs
  Reading specs from /u/fool/specs
  rename spec link to old_link
(and in my specs file there is/must be a new link, since programs still
link a-ok with it!)

so far, so good.

i do my linking with gcc (well, technically, libtool does it for me, but
still uses gcc, and still with "-specs /u/fool/specs"), and out pops a
binary.  unfortunately that binary has an RPATH (examined with solaris'
"ldd -s" and confirmed with a binary editor) that contains all the
directories in gcc's specs file, despite my specs file specifying not to
use them.

so my question is, how can i prevent this from happening?  editing the specs
file or building a private install of gcc that never included those dirs
in its specs file is an obvious answer but not terribly useful in my
environment--i rely on a compiler used by others which requires those
RPATH additions for normal operation, and my build is taking weeks (all
of KDE) during which it will be in use by said others.

i have experimented a bit with ld -nostdlib but i haven't gotten very far
with it (ie can't link a hello world).  to complicate matters on this front,
my resulting binaries must run on a range of ultrasparcs, and most
binaries show a link like this:

        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

whose path varies from machine type to machine type (ie:

        /usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
)

other things i've tried include attacking it from the ld.so.1 end via
various env vars.  LD_LIBRARY_PATH works but breaks other applications
which want the "standard" version of libs i've built (libpng for instance),
so it is not a viable solution.  LD_NOCONFIG seems like exactly what i
want, but i can find no evidence that it actually works in my
experimentation.  creating a /var/ld/ld.config with just my directories
in it also fails for at least gnu-ld-linked applications and is anyway
not going to work in my environment.

a real kludge that "solves" my problem is to change the RPATH in the
binary with a binary editor.  right now it's my best solution (munge
/lusr/lib to /lasr/lib and no libs are found there) but surely there's
some better way.

here's hoping that someone has been down this road before and can enlighten
me.  i'm happy to provide a ton more information upon request, but am not
sure what you'd want. 

thanks a million, in advance.

-- 
chris mccraw | unix wrangler | university of texas @austin computer sciences

Re: ld's RPATH versus gcc's

[Ian Lance Taylor]

Chris McCraw <fool@cs.utexas.edu> writes:

> i do my linking with gcc (well, technically, libtool does it for me, but
> still uses gcc, and still with "-specs /u/fool/specs"), and out pops a
> binary.  unfortunately that binary has an RPATH (examined with solaris'
> "ldd -s" and confirmed with a binary editor) that contains all the
> directories in gcc's specs file, despite my specs file specifying not to
> use them.
> 
> so my question is, how can i prevent this from happening?  editing the specs
> file or building a private install of gcc that never included those dirs
> in its specs file is an obvious answer but not terribly useful in my
> environment--i rely on a compiler used by others which requires those
> RPATH additions for normal operation, and my build is taking weeks (all
> of KDE) during which it will be in use by said others.

I don't know what is happening, but I do know that the linker's
handling of RPATH is quite simple.  The RPATH in the executable will
be to the directories specified using the -R or --rpath option.  If no
-R or --rpath is used, then the RPATH will be set to the value of the
environment variable LD_RUN_PATH.  If that is not, then the RPATH will
not be set.

So you should check the LD_RUN_PATH environment variable, and you
should check precisely how gcc is invoking the linker.  To see the
latter, pass -v on the link line, e.g., by putting it in LDFLAGS.

Ian

Re: ld's RPATH versus gcc's

[Chris McCraw]

On Wed, Jan 19, 2005 at 09:34:40PM -0500, Ian Lance Taylor wrote:
 
> I don't know what is happening, but I do know that the linker's
> handling of RPATH is quite simple.  The RPATH in the executable will
> be to the directories specified using the -R or --rpath option.  If no
> -R or --rpath is used, then the RPATH will be set to the value of the
> environment variable LD_RUN_PATH.  If that is not, then the RPATH will
> not be set.
> 
> So you should check the LD_RUN_PATH environment variable, and you
> should check precisely how gcc is invoking the linker.  To see the
> latter, pass -v on the link line, e.g., by putting it in LDFLAGS.

the root of my main problem turned out to be in libtool ignoring $CFLAGS
during linking of shared libraries.  thanks for the encouragement to keep
getting more verbosity out of ld, though it leads me here:

i think there is a third vector for RPATH entries--adding "-v -Wl,--verbose"
to the LDFLAGS shows the following output.  note particularly the line
with SEARCH_DIR.
those directories are mentioned nowhere in any specs file or options
passed via gcc or collect2--they are apparently internal to ld.  i am
only guessing here, since we have no directory
"/lusr/gnu/sparc-sun-solaris2.7/lib" but there was one around when this
LD was built.


---begin included---
gcc -v -specs /u/fool/specs -v -Wl,--verbose -o .libs/esdcat esdcat.o  ./.libs/libesd.so -L/lusr/opt/kde-3.3.2/lib /lusr/opt/kde-3.3.2/lib/libaudiofile.so -lm -lrt -lresolv -lsocket -Wl,--rpath -Wl,/lusr/opt/kde-3.3.2/lib                   Reading specs from /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs
Reading specs from /u/fool/specs
rename spec link to old_link
Configured with: /u/fool/Work/build/gcc-3.4.3/configure --prefix=/lusr/opt/gcc-3.4.3 --with-gnu-as --with-as=/lusr/gnu/bin/as --with-gnu-ld --with-ld=/lusr/gnu/bin/ld --enable-languages=c,c++,f77,objc,java,ada : (reconfigured) /u/fool/Work/build/gcc-3.4.3/configure --prefix=/lusr/opt/gcc-3.4.3 --with-gnu-as --with-as=/lusr/gnu/bin/as --with-gnu-ld --with-ld=/lusr/gnu/bin/ld --enable-languages=c,c++,f77,objc,java,ada                                                             Thread model: posix
gcc version 3.4.3
 /lusr/opt/gcc-3.4.3/libexec/gcc/sparc-sun-solaris2.9/3.4.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -R/lusr/kde3/lib -R/lusr/opt/gcc-3.4.3/lib -R/lusr/BerkeleyDB.4.2/lib -R/lusr/ssl/lib -R/lusr/netpbm/lib -L/lusr/kde3/lib -L/lusr/opt/gcc-3.4.3/lib -L/lusr/BerkeleyDB.4.2/lib -L/lusr/ssl/lib -L/lusr/netpbm/lib -L/lusr/ssl/lib -o .libs/esdcat /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crt1.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtbegin.o -L/lusr/opt/kde-3.3.2/lib -L/lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../.. --verbose esdcat.o ./.libs/libesd.so /lusr/opt/kde-3.3.2/lib/libaudiofile.so -lm -lrt -lresolv -lsocket --rpath /lusr/opt/kde-3.3.2/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtend.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtn.o                                                             GNU ld version 2.13.2.1
  Supported emulations:
   elf32_sparc
   elf64_sparc
GNU ld version 2.13.2.1
  Supported emulations:
   elf32_sparc
   elf64_sparc
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-sparc", "elf32-sparc",
          "elf32-sparc")
OUTPUT_ARCH(sparc)
ENTRY(_start)
SEARCH_DIR("/lusr/gnu/sparc-sun-solaris2.7/lib"); SEARCH_DIR("/lusr/gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/ccs/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");

---end included---

SEARCH_DIR("/lusr/gnu/sparc-sun-solaris2.7/lib"); SEARCH_DIR("/lusr/gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/ccs/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");




gcc -v -specs /u/fool/specs -v -Wl,--verbose -o .libs/esdcat esdcat.o  ./.libs/libesd.so -L/lusr/opt/kde-3.3.2/lib /lusr/opt/kde-3.3.2/lib/libaudiofile.so -lm -lrt -lresolv -lsocket -Wl,--rpath -Wl,/lusr/opt/kde-3.3.2/lib
Reading specs from /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs
Reading specs from /u/fool/specs
rename spec link to old_link
Configured with: /u/fool/Work/build/gcc-3.4.3/configure --prefix=/lusr/opt/gcc-3.4.3 --with-gnu-as --with-as=/lusr/gnu/bin/as --with-gnu-ld --with-ld=/lusr/gnu/bin/ld --enable-languages=c,c++,f77,objc,java,ada : (reconfigured) /u/fool/Work/build/gcc-3.4.3/configure --prefix=/lusr/opt/gcc-3.4.3 --with-gnu-as --with-as=/lusr/gnu/bin/as --with-gnu-ld --with-ld=/lusr/gnu/bin/ld --enable-languages=c,c++,f77,objc,java,ada
Thread model: posix
gcc version 3.4.3
 /lusr/opt/gcc-3.4.3/libexec/gcc/sparc-sun-solaris2.9/3.4.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -R/lusr/kde3/lib -R/lusr/opt/gcc-3.4.3/lib -R/lusr/BerkeleyDB.4.2/lib -R/lusr/ssl/lib -R/lusr/netpbm/lib -L/lusr/kde3/lib -L/lusr/opt/gcc-3.4.3/lib -L/lusr/BerkeleyDB.4.2/lib -L/lusr/ssl/lib -L/lusr/netpbm/lib -L/lusr/ssl/lib -o .libs/esdcat /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crt1.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtbegin.o -L/lusr/opt/kde-3.3.2/lib -L/lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../.. --verbose esdcat.o ./.libs/libesd.so /lusr/opt/kde-3.3.2/lib/libaudiofile.so -lm -lrt -lresolv -lsocket --rpath /lusr/opt/kde-3.3.2/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtend.o /lusr/opt/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtn.o
GNU ld version 2.13.2.1
  Supported emulations:
   elf32_sparc
   elf64_sparc
GNU ld version 2.13.2.1
  Supported emulations:
   elf32_sparc
   elf64_sparc
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-sparc", "elf32-sparc",
          "elf32-sparc")
OUTPUT_ARCH(sparc)
ENTRY(_start)
SEARCH_DIR("/lusr/gnu/sparc-sun-solaris2.7/lib"); SEARCH_DIR("/lusr/gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/ccs/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
   __DYNAMIC = 0;    */
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0x10000 + SIZEOF_HEADERS;

Re: ld's RPATH versus gcc's

[Andreas Schwab]

Chris McCraw <fool@cs.utexas.edu> writes:

> i think there is a third vector for RPATH entries--adding "-v -Wl,--verbose"
> to the LDFLAGS shows the following output.  note particularly the line
> with SEARCH_DIR.

This is the link-time library search path, which you can extend with -L.
It's coming from the default linker script, which is usually compiled in,
but also installed in $datadir/ldscripts.  This search path does not
contribute to the runtime search path by itself.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ld's RPATH versus gcc's

[Chris McCraw]

On Fri, Jan 21, 2005 at 12:46:56AM +0100, Andreas Schwab wrote:
> Chris McCraw <fool@cs.utexas.edu> writes:
> 
> > i think there is a third vector for RPATH entries--adding "-v -Wl,--verbose"
> > to the LDFLAGS shows the following output.  note particularly the line
> > with SEARCH_DIR.
> 
> This is the link-time library search path, which you can extend with -L.

can you replace it completely?  i found -nostdlib beyond my simple
reverse engineering skills, though now that i've seen the output of
a normal link with --verbose, i might be able to manage it.


> It's coming from the default linker script, which is usually compiled in,
> but also installed in $datadir/ldscripts.

so does changing the script in place have any effect on compiling, or is it
just an example which you can copy, change, and use with ld -T ?

Re: ld's RPATH versus gcc's

[Andreas Schwab]

Chris McCraw <fool@cs.utexas.edu> writes:

> can you replace it completely?  i found -nostdlib beyond my simple
> reverse engineering skills, though now that i've seen the output of
> a normal link with --verbose, i might be able to manage it.

You can replace it either with -nostdlib or by using a different linker
script.

>> It's coming from the default linker script, which is usually compiled in,
>> but also installed in $datadir/ldscripts.
>
> so does changing the script in place have any effect on compiling, or is it
> just an example which you can copy, change, and use with ld -T ?

The linker scripts for the default emulation are compiled into the linker
binary.  To change them you have to use -T and point it to a modified
copy.  For non-default emulations the scripts are read from the
filesystem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."