rpath

Alexandre Oliva aoliva@redhat.com
Sun Jun 25 21:48:00 GMT 2000


On Jun 25, 2000, Per Bothner <per@bothner.com> wrote:

> But people whose opinion I respect have argued emphatically that
> having the compiler set -rpath causes more problems than it solves
> and is a big mistake.

Indeed, there are many problems related with the compiler setting
rpath.

First of all, it should do it in a way that doesn't prevent the user
from having his own rpath settings, and these may come in the form of
command line arguments or environment variables, so gcc/gcj would have
to know about such flags and their meanings to do The Right Thing
(TM).  One of the issues that makes this more involving is that, on
certain platforms, multiple -rpath flags accumulate; on others, only
the last one prevails.  I don't remember of any platform in which an
environment variable such as LD_RUN_PATH is taken into account when an
-rpath-like flag is given, but I may be wrong.  There are also some
platforms in which there's no such thing as an -rpath flag, you must
set environment variables instead.  And there's also the issue of
whether the compiler-specific directory(ies?) should be placed in
front of user-supplied ones of after them.  There are arguments for
and against both behaviors.

The main complaint about having -rpath encoded into executables is
that, on POSIX-compliant platforms, LD_LIBRARY_PATH is only taken into
account after the -rpath-specified PATH is searched.  Therefore, if
you move a library and install another one with the same SONAME in the
same directory, setting LD_LIBRARY_PATH to the new location of the old
library won't get you the old library.  This was a major pain in the
transition from libc5 to glibc, because libraries were replaced with
incompatible names without having their SONAMEs changed.  The real
mistake was that SONAMEs hadn't changed, but people expected it to
just work anyway.

There's also the issue of the compiler supplying a certain -rpath even
though libraries are going to be installed elsewhere.  That's why a
compiler shouldn't automatically supply -rpath for arbitrary
libraries: they often aren't installed yet, and having their build
directory hard-coded into binaries may become a source of security
problems later on.

However, this argument doesn't apply as clearly for libraries
implicitly supplied by the compiler.  IMO, the compiler should arrange
for any libraries it implicitly links in to be found at run-time,
otherwise their inclusion isn't fully transparent.  But then, there's
the problem of replacing libraries with incompatible ones.  This can
certainly be simplified by having libraries installed in
version-specific directories.  However, this may reduce/remove any
gains from shared library caches, since such version-specific
directories wouldn't be listed in /etc/ld.so.conf.  I'm not sure this
loss would be significant, though.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



More information about the Java mailing list