Hrvoje> Martin Buchholz <martin(a)xemacs.org&gt; writes: Hrvoje> [...] Hrvoje> I agree with your view -- in fact, I was the one who bitched about the Hrvoje> problem under Solaris which I used at the time. Hrvoje> However, Steve's technical argument against this method was that Linux Hrvoje> makes use of ld.so.conf to ensure old versions of executables for Hrvoje> libraries that need them. This way a libc5 program "knows" that old Hrvoje> libraries are in a "libc5-compat" directory. If we hardcode the Hrvoje> runtime library path into the executable, we lose that capability, Hrvoje> don't we? Well, the way it *should* work is that the RPATH baked into the executable is searched first, and then, if not all libraries are found, /etc/ld.so.conf is searched, and if not all libraries are found, the hardcoded /usr/lib is searched. Does it really not work like that? It might depend on your version of Linux. ..... Hmmmmm. OK, I actually tried it. On my system (Red Hat Linux 6.0) I experimented and found that it works exactly as I expected it to be: - the RPATH specified via -Wl,-rpath=... was used, _but_ if the shared libraries cannot be found there, the system falls back to /etc/ld.so.conf. The world is (relatively) sane. I feel this basically refutes Steve's previous objections, assuming this behavior to be true of modern Linux systems. ..... ok, to be sure, I just tried it as well on Linux 5.2, which is based on kernel 2.0.36, glibc 2.0. It works there the same way. shell transcript follows: (martin＠lasker) ~/src $ cp /usr/X11R6/lib/libX11.so* tt/. (martin＠lasker) ~/src $ gcc29 lib.c -Wl,-rpath=/home/martin/src/tt -L/usr/X11R6/lib -lX11 (martin＠lasker) ~/src $ ldd -v ./a.out libX11.so.6 => /home/martin/src/tt/libX11.so.6 (0x40014000) libc.so.6 => /lib/libc.so.6 (0x400b7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Version information: ./a.out: libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /home/martin/src/tt/libX11.so.6: libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /lib/libc.so.6: ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2 (martin＠lasker) ~/src $ ls -l tt total 2268 -rwxr-xr-x 1 martin martin 769708 Jan 16 03:58 libX11.so -rwxr-xr-x 1 martin martin 769708 Jan 16 03:58 libX11.so.6 -rwxr-xr-x 1 martin martin 769708 Jan 16 03:58 libX11.so.6.1 (martin＠lasker) ~/src $ ./a.out (martin＠lasker) ~/src $ rm -rf tt (martin＠lasker) ~/src $ ldd -v ./a.out libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4001a000) libc.so.6 => /lib/libc.so.6 (0x400b7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Version information: ./a.out: libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /usr/X11R6/lib/libX11.so.6: libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /lib/libc.so.6: ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2 (martin＠lasker) ~/src $ ./a.out (martin＠lasker) ~/src $ cat lib.c #include <stdio.h> int main (int argc, char *argv[]) { XOpenDisplay ("hello world\n"); return 0; } (martin＠lasker) ~/src $ cat /etc/ld.so.conf /usr/X11R6/lib /usr/lib /usr/i486-linux-libc5/lib

VK> On Sun, 16 Jan 2000 04:32:41 PST, Martin Buchholz said: VK> Not being a heavy-duty Linuxoid yet, if you have an older binary VK> that wants the libc5 version of -lc how does that get resolved VK> if it finds a libc6 version via -rpath? Or are we being careful VK> to only specify -rpath for things not usually found by ld.so.conf? VK> Basically, what mechanism are we using to make sure that Things VK> Dont Suck if we link against a now-current library, but the sysadmin VK> then uses ld.so.conf to move it around for compatability while VK> installing a new version of the library? VK> Or am I missing something due to too many nights of 5 hours sleep? ;) The new library should have a new major version number or should use some other magic to make sure old binaries don't use it. Imagine a system with all libs in /usr/lib. /etc/ld.so.conf contains only /usr/lib. The system is upgraded to a new set of libraries. All the original libs in /usr/lib are moved to /usr/moldy/lib, and then /usr/lib is repopulated. Contents of /etc/ld.so.conf are changed to /usr/lib /usr/moldy/lib Now imagine starting an old app, one that needs to use the old libs. Because /usr/lib comes first in the search path, there must be some mechanism used by the dynamic linker to prevent the old apps from using the new libraries. That same mechanism will also prevent that if an explicit rpath is used when linking. The design of glibc also includes the concept of `symbol versioning'. The intent is that you can always upgrade your libc version, and old apps will continue to use old versions of particular symbols. So this dance of old libraries should finally come to a stop. After the a.out->elf and now libc5->glibc transition, there are no more gut-wrenching transitions planned in the Linux world. Martin