Re: -rpath with libtool and Debian Linux
>>>>> "Alexandre" == Alexandre Oliva <firstname.lastname@example.org> writes:
Alexandre> You might have included my suggestion to prevent having
Alexandre> to move libraries in the first place: creating a
Alexandre> libc6-specific directory right now, instead of
Alexandre> installing libraries in /usr/lib and having to move
Alexandre> them into another directory when libc7 should be
This is rather frustrating, because then we will need to make a
/lib/libc6, /usr/lib/libc6, /usr/X11R6/libc6, /usr/local/lib/libc6..
it never ends. :)
Alexandre> More than that (and it was my fault to have failed to
Alexandre> mention that before): libtool will hard-code the
Alexandre> installation directory of the library into the `libdir'
Alexandre> variable of the .la script it installs. Therefore, if
Alexandre> one moves the library then tries to link with the .la
Alexandre> file, he loses. There's also the dlopening issue:
Alexandre> libltdl (to be released with libtool 1.3) will dlopen a
Alexandre> library in the directory pointed to by `libdir' too.
I've never understood what the .la scripts are for. Why are they
installed into /usr/lib/, where libraries live? This is kind of
off-the-subject, but they have always confused me, and I delete
them out of any libtool-using library package I maintain.
Alexandre> In general, I feel that moving libraries around is a
Alexandre> very bad idea, because it will lead to failure most of
Alexandre> the times, and that's why I don't feel libtool should
Alexandre> help people doing that.
With Debian and Red Hat, it's totally the opposite. Moving libraries
around is what leads to upgrades being possible.
Alexandre> The issue is very complex because we can't think just
Alexandre> of GNU/Linux with all its bells and whistles, because
Alexandre> libtool is supposed to present an homogeneous, portable
Alexandre> interface to creating libraries.
Totally agreed. You are worrying just a bit too much about this,
though -- we don't need to worry about a switch that has to decide
WHEN to disable -rpath, just a switch that understands, "Okay, the
builder knows what he's talking about, no -rpath is fine with me".
Brought to you by the letters V and D and the number 3.
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.