RUNPATH truncated at some point during loading of shared object

[Poor Yorick]

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