[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -rpath with libtool and Debian Linux

On Jan 27, 1999, Ben Gertzfield <che@debian.org> wrote:

> This is bad for Debian, because in all binary packaging systems,
> shared libraries can and will be moved around from time to time, as
> policy and major upgrades (like libc5 -> libc6) mandate.

You might have included my suggestion to prevent having to move
libraries in the first place: creating a libc6-specific directory
right now, instead of installing libraries in /usr/lib and having to
move them into another directory when libc7 should be released.

> However, Alexandre Oliva <oliva@dcc.unicamp.br> brings up an important
> point: -rpath is necessary if one is installing libraries and binaries
> linked to those libraries in one's home directory, or if your Unix has
> no support for library search paths via environment variables like

More than that (and it was my fault to have failed to mention that
before): libtool will hard-code the installation directory of the
library into the `libdir' variable of the .la script it installs.
Therefore, if one moves the library then tries to link with the .la
file, he loses.  There's also the dlopening issue: libltdl (to be
released with libtool 1.3) will dlopen a library in the directory
pointed to by `libdir' too.

In general, I feel that moving libraries around is a very bad idea,
because it will lead to failure most of the times, and that's why I
don't feel libtool should help people doing that.

> Basically, I have been asking Alexandre if it's possible to add a
> --no-rpath option to libtool when calling it to tell it to not use
> -rpath when linking binaries, but he refused, saying he'd have to port
> that to 'hundreds of platforms'.

Actually, not issuing -rpath or equivalent is quite easy to do, but
choosing *when* not to do it is the part that is hard to port.  Thomas 
Tanner has suggested that we could omit the -rpath switch for
libraries that are supposed to be installed in directories listed in
the default search path.  However, the default search PATH might
change, and, even if it did not, it would be possible to link an
application with a library in, say, /usr/local/lib, and then find out
that at run-time it loads a library with the same name in /usr/lib,
because /usr/lib appears first in the standard search path.

The other issue is *how* to specify that -rpath should be ommitted.
Should it be a configure option, that would permanently disable any
-rpath switches?  Or should it be an additional argument to the
libtool script at program-linking time?  Or should it be specified at
library linking time, with one of three options: hardcode path in the
library, hardcode path in any program linked with it, or do not
hardcode path at all?  Or something else?  What to do on a platform
that doesn't support the requested hardcoding strategy?

The issue is very complex because we can't think just of GNU/Linux
with all its bells and whistles, because libtool is supposed to
present an homogeneous, portable interface to creating libraries.

Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
Universidade Estadual de Campinas, SP, Brasil

Reply to: