On Jan 28, 1999, Bernard Dautrevaux <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil