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 behaviour. > I think that that is correct -- these _are_ overrides. They're > to be used when the default behaviour 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. -- 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
