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

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}
Universidade Estadual de Campinas, SP, Brasil

Reply to: