Use RPATH but not RUNPATH?

Question

This page - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - talks about the library search order in ld.so:

Unless loading object has RUNPATH: RPATH of the loading object, then the RPATH of its loader (unless it has a RUNPATH), ..., until the end of the chain, which is either the executable or an object loaded by dlopen Unless executable has RUNPATH: RPATH of the executable LD_LIBRARY_PATH RUNPATH of the loading object ld.so.cache default dirs 

And then suggest:

When you send binaries, use RPATH rather than RUNPATH, or make sure LD_LIBRARY_PATH is set before they start.

So, using RPATH with RUNPATH bad because RUNPATH cancels the cancellation of RPATH , so that indirect dynamic loading does not work properly? But why then RPATH become obsolete in favor of RUNPATH ?

Can someone explain the situation?

Answer 1

When you send a binary file, it would be nice to give users the opportunity to adapt the binary file to the specifics of their own system, including by setting up search paths in the library.

The user can usually configure LD_LIBRARY_PATH and /etc/ld.so.conf , both of which have lower priority than DT_RPATH , that is, you cannot override what is hardcoded in binary /etc/ld.so.conf , whereas if you use DT_RUNPATH instead, the user can override this with LD_LIBRARY_PATH .

(FWIW, I think ld.so.conf should also take precedence over DT_RUNPATH , but in any case, at least we have LD_LIBRARY_PATH ).

In addition, I strongly disagree with the proposal above to use DT_RPATH . IMO, it is best to use DT_RPATH not in DT_RUNPATH in the supplied binaries.

if

you supply all dependent libraries with your executables and want to make sure that JustWork (tm) after installation, in this case uses DT_RPATH .

Answer 2

The answer to the cold is exactly right; I wanted to just add some color from a recent glibc source reading ([master 8b0ccb2], in 2.17). To be clear, if the library is not found at the location specified by this level, the next level will be checked. If the library is found at a given level, the search stops.

Dynamic library search order:

• DT_RPATH in binary ELF if DT_RUNPATH is not set.
• LD_LIBRARY_PATH entries if setuid / setgid
• DT_RUNPATH in binary ELF format
• /etc/ld.so.cache if only -z nodeflib is specified at connection time
• / lib, / usr / lib if only -z nodeflib
• Done, not found.

Answer 3

But why then did RPATH become obsolete in favor of RUNPATH?

When DT_RPATH was entered, it took precedence over all other parameters. This made it impossible to redefine the library search path even for development purposes. Therefore, another parameter LD_RUNPATH was introduced, which has a lower priority than LD_LIBRARY_PATH.

For more information, see How to Write Shared Libraries , written by Ulrich Drepper .