Re: Installation proposal

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 27, 2002, Richard Henderson <rth@redhat.com> wrote:

> On Wed, Feb 27, 2002 at 12:32:27PM -0700, Tom Tromey wrote:
>> Don't shared libraries have to be relinked with knowledge of their
>> real install location?

> Not on sane systems.

> Libtool seems to be of the opinion that this is necessary
> everywhere, however.

Please do not spread mis-information about libtool.  You may have your
reasons to dislike libtool, but what you're saying is not true.

A sane system, to me, is one in which programs and libraries can find
their dependencies without the user having to resort to setting
LD_LIBRARY_PATH and *hoping* it will work, if they are installed in
the location they were configured for.

Libtool does in fact have to resort to relinking at install time in
some situations to guarantee this property.  I list such situations
below:

- on HPUX, when installing an executable linked using libtool that is
  linked with libtool libraries in their build-tree location.  That's
  because HPUX's linker doesn't support the equivalent of -rpath, so
  the executable must be relinked after the library is installed such
  that it can store the default pathname of the library into the
  executable.  This does not work for DESTDIR installations, and
  there's no way to overcome it on HPUX.

- on most other systems, when a libtool shared library is linked with
  another libtool shared library, the latter still being in its build
  tree.  Because libtool creates libraries in the build tree in such a
  way that they can be linked with and used in-place, it encodes
  build-tree pathnames into the library.  Then, at install time, it
  re-links libraries such that the work in the install tree.  Again,
  on HP-UX, DESTDIR installations don't work.


The former is a problem for GCJ executables on HPUX.  The latter would
be a problem for GCJ because it contains inter-library dependencies.
However, except on HPUX, it should work just fine, as long as a patch
that fixes relinking in DESTDIR installations is put in.  Assuming
we're actually going to `make install' into the install-tree hold
area, it would work just fine.  Except that executables and libraries
would be set up to find their dependencies in the final install tree,
so, if you already have earlier versions in there, your results may be
incorrect.

Messing up with shared libraries with inter-dependencies is very
dangerous business.  Nothing is as simple as you'd like and, and there
are some dynamic linkers in which LD_LIBRARY_PATH (or the equivalent)
won't do what you want.  In fact, on some systems there's no way to
override the path used to search for dependencies of shared library,
so the only hope is to get them correctly encoded into the shared
library itself.  Trying to fix it up with LD_LIBRARY_PATH afterwards
just won't work.

Beware!  You were warned :-)

-- 
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                Professional serial bug killer