Re: -rpath with libtool and Debian Linux

[Ian Lance Taylor <ian@cygnus.com>]

   Date: Wed, 3 Feb 1999 10:44:42 +0000 (GMT)
   From: Jules Bean <jmlb2@hermes.cam.ac.uk>

   And, as we've pointed out, changing the soname is not a practicable
   answer, until we have a cleverer automatic soname system.

One possibility would be a soname rewriting program.  It's a moot
point now, though.

   (Does symbol versioning fix this?  I don't know...)

Yes, it does.  Symbol versioning permits changing specific symbols in
a library as their interface changes, such that old programs get the
old symbol and new programs get the new symbol.  It requires a fair
bit of discipline on the part of the library maintainer, but at least
in principle nobody else has to worry about it.

   Whilst I'm glad that we've come to some agreement that its not necessary
   to use -rpath for system directories, for some appropriate definition of
   system directories (which is a decision which, for Debian, can be made at
   the distribution level, so we'll get it right), I am quite baffled that
   you still think it's right to enable it as default...

   I really don't see why it's clever to hardcode paths...  And I do see why
   it's clever to have a dynamic library which goes looking for its libs, and
   knows where to go...  This is in fact largely orthogonal to the
   'incompatible lib without soname change' argument.

Remember that the path set by -rpath is only a suggestion.  It's not
an error if a library is not found at runtime at the path where it was
at link time.  -rpath just adds to the search path used to find shared
libraries.

It's clever to hardcode paths to any shared libraries because it makes
it more likely that your program will be able to run without the
person running it having to set LD_LIBRARY_PATH.

Ian