Re: A question about RPATH

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On 20 December 2012 09:42, Andrew Haley wrote:
>
> The disadvantages of RPATH are well-documented.  Perhaps its usage is
> common on Solaris, but we don't much use it on Linux.

Speak for yourself. Linux distros might not, but that doesn't mean users don't.

As I said at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354#c9
"Whether you think LD_LIBRARY_PATH is more or less evil than RPATH is
your business, but I want to be able to make my own decision."

> Your problem is best solved by installing dependent libraries where
> ld.so can find them.  ldconfig can do this, but if these libraries
> are available as standard packages that's hugely preferable.

If I deploy code releases to dozens of production machines in
~produser/rel/appname/ver_x.y, at least once a week, should I keep
updating ld.so.conf to add ~produser/rel/appname/ver_x.y/lib for every
new appname/rel.x.y, and remove the paths to the older releases as
they get deleted off the boxes?  Or should I simply put executables in
~produser/rel/appname/ver_x.y/bin with RPATH=$ORIGIN/../lib and their
library dependencies in ~produser/rel/appname/ver_x.y/lib?  Using
RPATH with $ORIGIN ensures the right libs are found for a given
executable. The makefiles that build the code ensure
-Wl,-rpath,$ORIGIN/../lib is used and that's all that's needed, the
libraries will be found with no extra work, wherever they get
deployed, as long as the libs stay in ../lib relative to the exes..
Even if NFS was involved (it isn't) if the executables can be reached
then so can the libs, as they're on the same partition.
LD_LIBRARY_PATH would need to be constantly set to something different
if I want to use ~produser/rel/app1/ver_1.2 and
~produser/rel/app1/ver_1.3 and ~produser/rel/app2/ver_3.4 all at once,
let alone run multiple versions of the code in a dev or UAT env to
test and compare results. By using an RPATH containing $ORIGIN all
this can be done with only privs to write to ~produser, not superuser
privs or sudo access to ld.so.conf

ld.so obviously works best for packagers such as distros, or if people
deploying software to production have root access, or if you only have
one version of a library that all executables on the box want to use,
but RPATH is extremely useful for other (IMHO important) uses.

Rant over ;)