Re: Ian's solution [was: What hack in ld.so?]
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
Reply to: