> -----Original Message-----
> From: Alexandre Oliva [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 29, 1999 1:14 PM
> To: Richard Braakman
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> debian-devel@lists.debian.org; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: -rpath with libtool and Debian Linux
>
>
> On Jan 29, 1999, Richard Braakman <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva wrote:
> >> 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?
>
> > No, that's not how it works. To the best of my
> understanding, it works
> > by adding a "libc5 or libc6" field to its cache. When it looks for
> > a cached library, and it finds two entries, it picks the
> one with the
> > correct libc. It always searches all of its directories.
>
> > It allows -rpath and LD_LIBRARY_PATH to override this behavior.
> > I think that is correct -- these _are_ overrides. They're
> > to be used when the default behavior gets things wrong.
>
> Since -rpath is specified at program link time, and libc5 is supposed
> to be used only by old programs, it would be correct for ld.so to use
> /usr/lib/libc5 instead of /usr/lib if it finds that the program was
> linked with libc5. This would make the transition as transparent as
> possible, even for users that, inadvertently or not, have decided to
> use -rpath /usr/lib for their programs.
>
That sounds VERY sensible, although it's breaking the whole semantics of
-rpath... Anyway I'm now a bit confused: please could someone more
familiar than me with the *exact* way ld.so resolves library clarify
it's search rules:
If -rpath introduce some non-standard library (like -rpath
/home/foo/bar/lib) what happens? What I understood a while ago was the
following:
If the program needs some libfoobar.something, and it finds
libfoobar.so.5 in /home/foo/bar/lib, it will use it. period.
If the program needs some libfoobar.something, and it does not find it
in /home/foo/bar/lib, it looks in ld.so.cache, and select the one that
fit depending on dependants (like libc5 Vs libc6)
So far so good for me... (I expect the user to be a bit careful about
dependencies between packages it explicitly install on its system, that
is he do not install executable foo linked against libc5 that needs
library bar, that was build against libc6).
BUT it seems that if I also give -rpath /usr/lib, then ld.so will no
more check dependencies and then will load the libfoobar.so.whatever he
find in /usr/lib even if dependencies are broken
If that's true, I must admit that ld.so should at least warn about
dependencies clashes; but nevertheless libtool is meant to be able to
use non perfect systems, so libtool must avoid using -rpath in this
case.
Please, to try to clear up this thread, could someone familiar with
ld.so say exactly what happens on Linux (and possibly on other platforms
also).
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------
