executable RPATH question

[Rich Felker]

On Fri, Feb 06, 2015 at 01:00:07PM -0800, Steve Ellcey wrote:
> On Fri, 2015-02-06 at 10:30 +0100, Bernhard Reutner-Fischer wrote:
> > On February 6, 2015 8:23:27 AM GMT+01:00, Waldemar Brodkorb <wbx at openadk.org> wrote:
> > >> 
> > >> Original discussion:
> > >> 
> > >> http://lists.uclibc.org/pipermail/uclibc/2011-September/045757.html
> > >
> > >Do you have a patch which applies to master?
> > >Including an option...
> > 
> > I still think this is wrong. Just set the RUNPATH of the first lib correctly (and fix glibc):
> > 
> > http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies
> > 
> > The set of directories specified by a given DT_RUNPATH entry is
> > used to find only the immediate dependencies of the executable or
> > shared object containing the DT_RUNPATH entry. That is, it is used
> > only for those dependencies contained in the DT_NEEDED entries of
> > the dynamic structure containing the DT_RUNPATHentry, itself. One
> > object's DT_RUNPATHentry does not affect the search for any other
> > object's dependencies.
> 
> I don't think I would have any chance of getting glibc to change their
> behavior and I am not disagreeing with your claim that the current
> behavior is correct.  I just think people might want the alternative
> behavior and it would be nice to allow it as an option (but not by
> default).

I'm with glibc on this one. From a plausible usage case standpoint,
RPATH/RUNPATH should be searched back through the whole dependency
chain through which the target library is being pulled in, not just
the immediate dependent library. The canonical usage case is to copy
known-working .so files which were not built with RPATHs in them to an
application-specific lib dir and put the RPATH in the application's
main executable. I also support this type of usage in musl's dynamic
linker.

Rich