This page says about order for library search 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 suggests:
When you ship binaries, either use RPATH and not RUNPATH or ensure LD_LIBRARY_PATH is set before they are run.
So, using RPATH
with RUNPATH
is bad because RUNPATH
kind-of cancels RPATH
so indirect dynamic loading doesn't work as expected? But why then RPATH
got deprecated in favor of RUNPATH
?
Can somebody explain the situation?
Both rpath and runpath are used to specify directories to search for shared libraries(dynamic libraries). If you are not sure what shared libraries is, I have a story written on Static vs Dynamic libraries. Shared libraries are libraries which are not bundles along with the executable. They are loaded at the run time.
In computing, rpath designates the run-time search path hard-coded in an executable file or library. Dynamic linking loaders use the rpath to find required libraries. Specifically, it encodes a path to shared libraries into the header of an executable (or another shared library).
We can change RPATH or RUNPATH of a binary file by using the chrpath tool. Note that you cannot convert a RUNPATH back to RPATH. Note that the string of the new set of paths should be smaller or equal to the length of what was stored earlier in the binary.
$ORIGIN is a special variable that indicate actual executable filename. It is resolved to where the executable is at run-time, and can be quite useful when setting RPATH.
When you ship a binary, it's good to provide means for the users to accommodate the binary to the specifics of their own system, among other things, adjusting library search paths.
A user can generally tweak LD_LIBRARY_PATH
and /etc/ld.so.conf
, both of which are with lower precedence than DT_RPATH
, i.e. you can't override what is hardcoded in the binary, whereas if you use DT_RUNPATH
instead, a user can override it with LD_LIBRARY_PATH
.
(FWIW, I think ld.so.conf
should also take precedence over DT_RUNPATH
, but, anyway, at least we've got LD_LIBRARY_PATH
).
Also, I strongly disagree with the suggestion above to use DT_RPATH
. IMO, its best to use nether DT_RPATH
not DT_RUNPATH
in shipped binaries.
unless
you ship all your dependent libraries with your executables and wish to ensure that things JustWork(tm) after installation, in this case use DT_RPATH
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With