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: RUNPATH truncated at some point during loading of shared object

On Sunday 09 March 2008, Poor Yorick wrote:

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

> 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., which requires
> and, 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 in /path/to/lib.  A moment later, LD_DEBUG=libs
> reports that the value of RUNPATH is
> 	/some/other/path1:/some/other/path2
> and is not found.  So it looks like the value of RUNPATH has
> suddenly changed. has NEEDED entries for both and
>  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.

Attachment: signature.asc
Description: This is a digitally signed message part.

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