Gordon Matzigkeit writes: > Hi, all! > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries.
By, as far as I can tell, breaking the ABI. I suppose that an alternative hack would be not to take the DT_RPATH as cast is stone, but subject it to some kind of rewriting if the binary is found to use libc5. For example, you could try to quietly append "/libc5-compat" to every component, on the assumption that on a libc6-based system, all libc5 binaries will be moved to such locations. Another good point that was raised is that some systems, like IRIX, have environment variables that are used by rld (the run-time loader on IRIX) to select a whole different root (_RLD_ROOT), or just to have some directories searched before even DT_RPATH is checked (_RLD_PATH? I'll have to check). (Use of _RLD_ROOT, combined with the ability to extract a package under an alternate root is precisely what is required to get several incompatible packages to live together on a single system.) That having been said, I do believe that to use -rpath to specify system directories is a bad idea, if for no other reason than that it prevents users from using LD_LIBRARY_PATH to customize their environment. Instead they have to rely on non-standard extensions. I do realise that on Linux, thanks to the ldconfig mechanism, the set of system directories is rather fungible. On IRIX for example, the system directories for o32 binaries are /lib and /usr/lib, period. The case for using -rpath is a lot more clear-cut on some systems than on others. -- Olaf Weber