What hack in ld.so?

[Buddha Buck <bmbuck@acsu.buffalo.edu>]

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                      bmbuck@acsu.buffalo.edu
"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