This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
DT_RPATH from dependent lib ignored by ld?
- From: Adam Kemp <adam dot kemp at ni dot com>
- To: binutils at sourceware dot org
- Date: Wed, 19 Jan 2011 15:25:26 -0600
- Subject: DT_RPATH from dependent lib ignored by ld?
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