This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld's RPATH versus gcc's
- From: Ian Lance Taylor <ian at airs dot com>
- To: Chris McCraw <fool at cs dot utexas dot edu>
- Cc: binutils at sources dot redhat dot com
- Date: 19 Jan 2005 21:34:40 -0500
- Subject: Re: ld's RPATH versus gcc's
- References: <20050120000928.GP22279@fidleyhutch.cs.utexas.edu>
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