This is the mail archive of the 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: [PATCH 2/2 v5] gold: enable new dtags by default

On Tue, 4 Feb 2014, Cary Coutant wrote:

> (2) DT_RUNPATH is used only to search for direct dependencies of the
> object it's contained in, while DT_RPATH is used for indirect
> dependencies as well. (This difference is *not* mentioned in the
> gABI.) Again, the DT_RUNPATH behavior makes sense -- an object
> shouldn't have any awareness of its indirect dependencies, which may
> change over time.
> It seems to me that the cases where DT_RUNPATH causes breakage are
> broken as intended, and the second-level libraries that depend on
> third-level libraries should have an embedded DT_RUNPATH that says
> where to find them. Of course, since they've been working for so long,

Say you have a sysroot containing what's eventually intended to be some 
system's root filesystem.  None of the libraries therein should have RPATH 
or RUNPATH set - paths on the host or the system used for testing wouldn't 
work on the final target system, and on the final system the libraries 
will be in standard directories such as /usr/lib.  To build a test binary 
that uses the sysroot before it's installed in a root filesystem, you use 
-Wl,-dynamic-linker,/sysroot/< path> 
-Wl,-rpath,/sysroot/lib:/sysroot/usr/lib.  For this (which is the main 
purpose I use -rpath for at all, building programs to use non-installed 
libraries) to work reliably relies on all dependencies being found via 
that RPATH, both direct and indirect.  I consider this part of the 
semantics of the -rpath option; that is, generating DT_RUNPATH should be a 
different option such as -runpath.

Joseph S. Myers

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