In the thread on -rpath that is currently taking place on the debian-devel mailing list (quick summary: Debian developers say that -rpath should -not- be the default on Linux systems; libtool developers say that -rpath should be the default on all systems), Alexandre Oliva has repeatedly referred to an "incomplete hack" on the ld.so, either on linux systems or on Debian systems.
I would appreciate it if he would explain in detail what this hack is supposed to be. >From what he describes, it sounds like he thinks that the linker was modified to special-case the libc5/libc6 transition, to allow us to move old libraries that depended on libc5 into a special directory, and replace them with libraries that depended on libc6. He thinks the behavior is something like this: program foo depends on libfoo and libc6. ld.so searches /usr/lib for a compatable libfoo, and find it. It then loads /usr/lib/libfoo and /lib/libc6 into memory. program bar, on the otherhand, depends on libfoo and libc5. Instead of searching /usr/lib, ld.so recognises that bar was linked with libc5, and so special-case searches /usr/lib/libc5-compat -first-, before searching /usr/lib. Finding a libfoo in /usr/lib/libc5-compat, it links that in. It does not search /usr/lib at all then, and thus does not link in the libc6 version of libfoo This breaks in the presence of -rpath, because rpath tells it to use /usr/lib/libfoo, and that overrides the hacked special case libc5 for programs. This is not how I understand how the ld.so linker works on Linux systems. My understanding is that it caches the locations of all known versions of the libraries, and makes an intelligent decision as to which version to load. I think that it handles foo and bar above like so: program foo depends on libfoo and libc6. ld.so checks its cache, and finds /usr/lib/libfoo (which in turn depends on libc6), and /usr/lib/libc5-compat/libfoo (which in turn depends on libc5). Faced with both possible libraries, it decides that loading /usr/lib/libfoo is a better choice than /usr/lib/libc5-compat/libfoo. I'm not sure offhand why it decides so -- does it know that libc5 and libc6 are incompatable versions of the same library (different sonames), or does it feel that loading two libraries (libfoo, libc6) is better than loading three (libfoo, libc5, libc6). program bar, on the otherhand, depends on libfoo and libc5. again, ld.so checks its cache, and again finds /usr/lib/libfoo and /usr/lib/libc5-compat/libfoo, Faced with a similar decision as last time, it again chooses, this time feeling /usr/lib/libc5-compat/libfoo is a better choice. This breaks in the presense of -rpath, because with rpath, bar is not dependent on libfoo, but on /usr/lib/libfoo. -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice