RUNPATH truncated at some point during loading of shared object

[Mike Frysinger]

On Sunday 09 March 2008, Poor Yorick wrote:

first off, please fix your mail client.  it clearly has broken long line 
wrapping.

> Mike Frysinger wrote:
> > On Sunday 09 March 2008, Daniel Jacobowitz wrote:
> >> On Sun, Mar 09, 2008 at 05:16:59PM -0400, Poor Yorick wrote:
> >>> ldd shows that a certain shared object on my system can not find one
> >>> of its dependencies.  The output of LD_DEBUG=libs shows that RUNPATH
> >>> initially contains four colon-separated paths, but after finding the
> >>> first four dependencies, RUNPATH suddenly contains only the first
> >>> two of its original four paths.  Could anyone please explain why the
> >>> value of RUNPATH might be changing while loading is in progress?
> >>
> >> This is the difference between RPATH and RUNPATH.  RUNPATH only
> >> affects searches requested by the object containing the tag.
> >
> > well there are other differences as well ... such as ordering of search
> > paths at runtime
> >
> > btw, where do people get their copy of the ELF spec ?  the version 1.2
> > spec from the TIS committee is sorely out of date ...
>
> But I'm saying that I have an object, e.g. libA.so, which requires libB.so
> and libC.so, which are both in /path/to/lib.  LD_DEBUG=libs first reports
> that the value of RUNPATH is
>
> 	/some/other/path1:/some/other/path2:/some/other/path3:/path/to/lib
>
> and ldd finds libA.so in /path/to/lib.  A moment later, LD_DEBUG=libs
> reports that the value of RUNPATH is
>
> 	/some/other/path1:/some/other/path2
>
> and libB.so is not found.  So it looks like the value of RUNPATH has
> suddenly changed.  libA.so has NEEDED entries for both libB.so and libC.so.
>  Does the explanation above really explain this scenario?

as Daniel indicated, RUNPATH does not apply to the lookup paths the same way 
as RTPATH.  rather than us trying to guess at how you're doing things, post 
the output of `readelf -d` of each ELF object in question.

i'd also point out that `ldd` and all LD_* related variables are part of the C 
library (you're probably using glibc), not binutils.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20080310/accf11d0/attachment.sig>