This seems to be a feature of DT_RUNPATH that is do not follow transitive
dependencies.
The problem is ld linker since v2.27(debian), enables by default new dtags ( it
uses RUNPATH instead of RPATH), so some dependencies may not been found at
runtime. Of course add LD_LIBRARY_PATH env, will do
The problem comes from linker ld, which is in binutils.
** No longer affects: binutils (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1253638
Title:
dynamic linker does not use DT_RUNPATH
> I don't know if this is expected behavior, but it's certainly annoying
behavior. I'm writing an app that depends on libtcodxx.so, which in turn
depends on libtcod.so. I want to ship them both in the lib directory
next to my app. With RUNPATH as "$ORIGIN/lib", it finds the direct
dependency
This bug (if it's a bug) also affects sys-libs/glibc-2.23-r3 on Gentoo.
The Qt Blog has a post about this issue from 2011:
http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/
This may not be a bug: it is possible that DT_RUNPATH was never intended
to be transitive. However, if this is so, then
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: eglibc (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1253638
Title:
I don't know if this is expected behavior, but it's certainly annoying
behavior. I'm writing an app that depends on libtcodxx.so, which in turn
depends on libtcod.so. I want to ship them both in the lib directory
next to my app. With RUNPATH as "$ORIGIN/lib", it finds the direct
dependency
