Comment 4 for bug 1253638

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 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 (0x00007ffeb6bdf000)
        libtcmalloc_minimal.so.4 => /usr/x86_64-amazon-linux-gnu/usr/lib64/libtcmalloc_minimal.so.4 (0x00007f2592d85000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f2592a53000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f259283c000)
        libpthread.so.0 => /usr/x86_64-amazon-linux-gnu/lib64/libpthread.so.0 (0x00007f259261f000)
        libc.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libc.so.6 (0x00007f2592274000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f2591f76000)
        /usr/x86_64-amazon-linux-gnu/lib64/ld-linux-x86-64.so.2 (0x00007f2592fcc000)

  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 (0x00007ffec67c2000)
        libtcmalloc_minimal.so.4 => /usr/x86_64-amazon-linux-gnu/usr/lib64/libtcmalloc_minimal.so.4 (0x00007fb5208b0000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libstdc++.so.6 (0x00007fb52057e000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007fb520367000)
        libpthread.so.0 => /usr/x86_64-amazon-linux-gnu/lib64/libpthread.so.0 (0x00007fb52014a000)
        libc.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libc.so.6 (0x00007fb51fd9f000)
        libm.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libm.so.6 (0x00007fb51faa1000)
        /usr/x86_64-amazon-linux-gnu/lib64/ld-linux-x86-64.so.2 (0x00007fb520af7000)

  Notice that libm.so.6 resolves to the correct library.