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. I think the dynamic linker could be further changed to always ignore a library that would introduce a mixed libc5/libc6 linkage. That would give the correct behaviour even with these overrides. However, that only solves the _previous_ problem, not any future ones. A general solution would require that "soname" be split into a library name and a major version, so that the dynamic linker can detect incompatible versions of the same library. That would be a major change. Richard Braakman