Re: -rpath with libtool and Debian Linux
On Wed, Jan 27, 1999 at 05:07:30PM -0200, Alexandre Oliva wrote:
> 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.
So, in other words, you would have Debian violate FSSTND, FHS, and decades
or historical precedent simply because you are unwilling to fix brokenness
in libtool? I simply find this level of arrogance almost beyond
comprehension. To say that Debian and every other distribution that tries
to adhere to these standards (most do) is broken for trying to do so is
ludicrous.
> > 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
> > Linux's LD_LIBRARY_PATH.
But our Unix does have that support (no rpath necessary!)
> 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
How does one link with a script?
> released with libtool 1.3) will dlopen a library in the directory
> pointed to by `libdir' too.
Then how about fixing it?
> 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.
How come it only leads to failure when libtool is involved then?
> 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
Look, we're not picky. You put an option in there that Configure can pass
to it at compile time, that's fine.
> hardcode path at all? Or something else? What to do on a platform
> that doesn't support the requested hardcoding strategy?
Obviously you use what you have.
> 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.
Ohhh, I get it. We're supposed to ignore the functionality that we have
because others are still running on PDP-11s, right?
Of all the nerve, this has to take the cake. I have no problem with
maintaining compatibility, but when it comes to something like this, where
compatibility CAN be maintained while still allowing us to take advantage of
our features, to insist that we must ignore our features is outlandish.
John
Reply to: