Re: Problematic linking between glibc and shared libgcc

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 20, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> The argument for -rpath are that it makes things easier for users if
> you *don't* move stuff; the argument it against is that it makes
> things harder if you do.

This is not true.  If you do move stuff, you may have to set
LD_LIBRARY_PATH so that the moved libraries are still found, but
that's all.  I.e., it's no worse than having to set LD_LIBRARY_PATH
always, and, in the general case, it's better, because you don't have
to set LD_LIBRARY_PATH at all.

It only makes things harder if you *do* move stuff, *then* place new
libraries with the same SONAMEs in the original location, or if the
original location becomes inaccessible (say, the NFS server goes
down).

The first case isn't always wrong; sometimes you do want to start
using the new libraries.  But it's harder to tell, and using the older
libraries may be impossible, if LD_LIBRARY_PATH is searched after the
PATHs encoded in the binaries (as mandated by the POSIX specs).  But
then, this should only be a problem if the libraries are indeed
incompatible, in which case they shouldn't have the same SONAME.

The second case is always temporary.  I don't think it's enough of a
reason to have programs not finding their libraries by default.

-- 
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