Re: -rpath with libtool and Debian Linux
On Jan 28, 1999, Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
> You say the contract is "I want to find THERE the lib that does THIS.x
> and THAT.x"; I think (and that's at least true for Linux) the contract
> the compiler and linker has signed was twofold; it says:
> 1) "I will give you the library that makes THIS.x and THAT.x"
> 2) "The prefered library I want you to use to obtain THIS and THAT
> is there and makes THIS.x and THAT.x"
> Now you trick it with -rpath in finding both the ".x" and THERE and all
> the problem comes from there...
> An analogy: When I wand to get hot water in restrooms, I just look at
> the tap, and turn the red one; I do not INSIST on opening the left one,
> risking to get cold water...
Good analogy. What's happening here is that Debian is placing the red
lable on the cold water tap. I.e., they're replacing a library with
an incompatible version of it, and getting in trouble because some
programs are now getting cold water where they expected hot water.
> Under Linux at least the incompatibilities we are talking here ARE
> managed by the dynamic linker, IFF we do not trick it saying him (using
> -rpath) "Do not be smart, just load the library from there". YOU are
> breaking the Linux contract...
ld.so is trying to outsmart everybody, but it is not smart enough to
do it. When you moved libc5-compatible libraries from /usr/lib to
/usr/lib/libc5, you established a rule that, if any program was linked
with libc5, it should look for libraries in /usr/lib/libc5 first,
right? Then why doesn't ld.so follow this rule, by replacing /usr/lib
with /usr/lib/libc5 when it finds this directory in the rpath too?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: