This may not be a bug: it is possible that DT_RUNPATH was never intended to be transitive. However, if this is so, then DT_RPATH should not have been deprecated, as DT_RUNPATH does not fully replicate its behavior (at a lower precedence than LD_LIBRARY_PATH).
My use case: I have a cross-compiling toolchain setup to allow me to compile binaries for the Amazon Linux distribution, which has older everything than my host system. To test the compiled binaries on my host system, I set LD_RUN_PATH and -Wl,-dynamic-linker when linking so that the Amazon-versioned libraries are used instead of my host system's libraries. The particular problem I'm experiencing is that libstdc++.so.6 needs libm.so.6, but the latter is not loaded from the proper location when my binary uses DT_RUNPATH instead of DT_RPATH.
Compare:
* When I link my binary with -Wl,--enable-new-dtags (the default on Gentoo):
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: blog.qt. io/blog/ 2011/10/ 28/rpath- and-runpath/
http://
This may not be a bug: it is possible that DT_RUNPATH was never intended to be transitive. However, if this is so, then DT_RPATH should not have been deprecated, as DT_RUNPATH does not fully replicate its behavior (at a lower precedence than LD_LIBRARY_PATH).
My use case: I have a cross-compiling toolchain setup to allow me to compile binaries for the Amazon Linux distribution, which has older everything than my host system. To test the compiled binaries on my host system, I set LD_RUN_PATH and -Wl,-dynamic-linker when linking so that the Amazon-versioned libraries are used instead of my host system's libraries. The particular problem I'm experiencing is that libstdc++.so.6 needs libm.so.6, but the latter is not loaded from the proper location when my binary uses DT_RUNPATH instead of DT_RPATH.
Compare:
* When I link my binary with -Wl,--enable- new-dtags (the default on Gentoo):
$ ldd out/x86_ 64-amazon- linux-gnu/ engine
linux- vdso.so. 1 (0x00007ffeb6bd f000)
libtcmalloc_ minimal. so.4 => /usr/x86_ 64-amazon- linux-gnu/ usr/lib64/ libtcmalloc_ minimal. so.4 (0x00007f2592d8 5000)
libstdc+ +.so.6 => /usr/lib/ gcc/x86_ 64-amazon- linux-gnu/ 4.8.3/libstdc+ +.so.6 (0x00007f2592a5 3000)
libgcc_ s.so.1 => /usr/lib/ gcc/x86_ 64-amazon- linux-gnu/ 4.8.3/libgcc_ s.so.1 (0x00007f259283 c000)
libpthread. so.0 => /usr/x86_ 64-amazon- linux-gnu/ lib64/libpthrea d.so.0 (0x00007f259261 f000) 64-amazon- linux-gnu/ lib64/libc. so.6 (0x00007f259227 4000) 6000)
/usr/x86_ 64-amazon- linux-gnu/ lib64/ld- linux-x86- 64.so.2 (0x00007f2592fc c000)
libc.so.6 => /usr/x86_
libm.so.6 => /lib64/libm.so.6 (0x00007f2591f7
Notice that libm.so.6 resolves to the system library in /lib64.
* When I link my binary with -Wl,--disable- new-dtags:
$ ldd out/x86_ 64-amazon- linux-gnu/ engine
linux- vdso.so. 1 (0x00007ffec67c 2000)
libtcmalloc_ minimal. so.4 => /usr/x86_ 64-amazon- linux-gnu/ usr/lib64/ libtcmalloc_ minimal. so.4 (0x00007fb5208b 0000)
libstdc+ +.so.6 => /usr/lib/ gcc/x86_ 64-amazon- linux-gnu/ 4.8.3/libstdc+ +.so.6 (0x00007fb52057 e000)
libgcc_ s.so.1 => /usr/lib/ gcc/x86_ 64-amazon- linux-gnu/ 4.8.3/libgcc_ s.so.1 (0x00007fb52036 7000)
libpthread. so.0 => /usr/x86_ 64-amazon- linux-gnu/ lib64/libpthrea d.so.0 (0x00007fb52014 a000) 64-amazon- linux-gnu/ lib64/libc. so.6 (0x00007fb51fd9 f000) 64-amazon- linux-gnu/ lib64/libm. so.6 (0x00007fb51faa 1000)
/usr/x86_ 64-amazon- linux-gnu/ lib64/ld- linux-x86- 64.so.2 (0x00007fb520af 7000)
libc.so.6 => /usr/x86_
libm.so.6 => /usr/x86_
Notice that libm.so.6 resolves to the correct library.