How executable's RPATH/RUNPATH affects .so's dlopen

[Stephan Bergmann <sbergman at redhat dot com>]

What I'm observing (at least with Fedora 17 glibc 2.15) is the following:

I have an executable E that links to libA.so, and libA.so in turn calls 
dlopen("B.so") (w/o a slash in the path).  All of E, libA.so, B.so are 
in the same directory, and libA.so has neither RPATH nor RUNPATH settings.

Now, if E contains RPATH=$ORIGIN but no RUNPATH, libA.so's call to 
dlopen("B.so") will search on E's RPATH and succeed.

However, if E contains both RPATH=$ORIGIN and RUNPATH=$ORIGIN, libA.so's 
call to dlopen("B.so") will neither search on E's RPATH (which is 
clearly by design) nor on E's RUNPATH (*) and fail.

From the information I find 
(<http://sourceware.org/bugzilla/show_bug.cgi?id=13945> "RUNPATH 
behaviour is not transitive," linking to 
<http://sourceware.org/ml/libc-hacker/2002-11/msg00011.html> "Re: 
[PATCH] Honor executables DT_RUNPATH for dlopen"), it looks like (*) is 
by design rather than in error, but I'm not entirely sure, as it would 
contradict the dlopen(3) manpage: "If the executable file for the 
calling program contains a DT_RUNPATH tag, then the directories listed 
in that tag are searched."

Can anybody clarify this?

Thanks,
Stephan