DT_RPATH from dependent lib ignored by ld?

[Adam Kemp <adam dot kemp at ni dot com>]

I am running into an issue linking, and I'm trying to figure out if it's a 
bug, an error in the documentation, or if I'm missing something.

According to the ld man page:

"The linker uses the following search paths to locate required shared 
libraries:
...
6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" 
of a shared library are searched for shared libraries needed by it. The
               "DT_RPATH" entries are ignored if "DT_RUNPATH" entries 
exist."

This implies to me that if I am building a binary foo which depends on a 
shared library libbar.so which depends on libbaz.so, and libbar.so has a 
DT_RPATH set so that it can find libbaz.so, then I should not have to do 
anything special to help the linker find libbaz.so. I should be able to 
just tell the linker how to find libbar.so, and as long as libbar.so can 
find libbaz.so then the link should succeed.

Unfortunately, this is not what I'm seeing. If I try the above scenario 
then I get a warning from the linker that it can't find libbaz.so and then 
unresolved symbols for anything that would have been in libbaz.so. I can 
run ldd on libbar.so, and it finds libbaz.so without a problem. I can also 
use readelf -d on libbar.so to verify that it has a DT_RPATH set. I can 
even tell it to ignore sharedlib undefined symbols 
(--allow-sharedlib-undefined) so that it links successfully, and the end 
result runs. All of this to me suggests that the linker is not paying any 
attention to the DT_RPATH of libbar.so. In that case either that's a bug 
or the documentation is wrong.

Or can someone explain to me what I'm doing wrong?

I can provide a simple set of test files if the above description is 
confusing.

Thanks.
--
Adam Kemp
adam.kemp@ni.com
(512) 683-6058