This is the mail archive of the binutils@sourceware.org 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


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 ...
-mike

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?

--
Yorick



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