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
