When building a binary or library, specifying the rpath
, i.e.
-Wl,rpath,
tells the linker where to find the
In the case of rpath
, it makes no sense to use a relative path, since a relative path will be relative to the current working directory, NOT relative to the directory where the binary/library was found. So it simply won't work for executables found in $PATH
or libraries in pretty much any case.
Instead, you can use the $ORIGIN
"special" path to have a path relative to the executable with-Wl,-rpath,'$ORIGIN'
-- note that you need quotes around it to avoid having the shell interpret it as a variable, and if you try to do this in a Makefile, you need $$
to avoid having make interpret the $
as well.
What is the UNIX philosphy regarding absolute and relative paths here?
Using relative path makes an executable that only works when invoked from a particular directory, which is almost never what you want. E.g. if the executable is in /app/foo/bin/exe
and has DT_RUNPATH
of lib/
, and a dependent library is in /app/foo/lib/libfoo.so
, then the exe
would only run when invoked from /app/foo
, and not when invoked from any other directory.
Using absolute path is much better: you can do cd /tmp; /app/foo/bin/exe
and have the executable still work. This is still however less than ideal: you can't easily have multiple versions of the binary (important during development), and you dictate to end-users where they must install the package.
On systems that support $ORIGIN
, using DT_RUNPATH
of $ORIGIN/../lib
would give you an executable what works when installed anywhere and invoked from any directory, so long as relative paths to bin/
and lib/
are preserved.