This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld's RPATH versus gcc's


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]