dynamic linker does not use DT_RUNPATH for transitive dependencies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eglibc (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
$ lsb_release -rd
Description: Ubuntu 13.10
Release: 13.10
$ uname -a
Linux mhassert 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$gcc -dumpversion
4.8
$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913
$ LC_ALL=C apt-cache policy libc-bin
libc-bin:
Installed: 2.17-93ubuntu4
* What you expected to happen
Binaries with DT_RPATH or DT_RUNPATH behaving identical in the absence of LD_LIBRARY_PATH
* What happened instead
DT_RUNPATH not searched for transitive dependencies.
When running a binary that depends on custom libraries which in turn depend on custom libraries, hard-coded search paths in DT_RUNPATH behave differently from those in DT_RPATH.
Paths in DT_RPATH are being considered for everything that is dynamically loaded, even dependencies of dependencies. Paths in DT_RUNPATH seem being considered only for direct dependencies of the binary.
Searching the web I think that the one and only difference between DT_RPATH and DT_RUNPATH should be that DT_RPATH is considered _before_ LD_LIBRARY_PATH and DT_RUNPATH _afterwards_. In the absence of LD_LIBRARY_PATH there should be no difference at all.
I stumbled upon this problem when switching from "ld" to "gold" for the linker. The default for ld on Ubuntu 13.10 is "--disable-
In the attached minimal example
- the binaries rpath and runpath both depend on libb but not directly on liba.
- libb depends on liba.
- liba and libb are linked without any hard-coded library paths.
- rpath and runpath are linked with hard-coded library paths for both liba and libb
- rpath is linked with --disable-new-dtags (producing DT_RPATH)
- rpath is linked with --enable-new-dtags (producing DT_RUNPATH)
To test, please run make all and observe how "rpath" works while "runpath" fails to find liba at runtime.
Status changed to 'Confirmed' because the bug affects multiple users.