modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)

[Edward Peschko]

> You say "the applications *may* depend on newer glibc features" ?
> You should find out for sure.  The best way to find out is to
> try.  Which Linux environments do you need your apps to run in?
> Which version of glibc is installed on those systems?
> You're almost certain to need nothing earlier than glibc-2.2.3
> (and I think you can build safely with glibc-2.2.5 and have
> that work, but I'm not sure; maybe somebody else could comment).
> 
> You say the apps may or may not be LSB compliant.  Have you
> tried building them under the LSB yet?


well, no - I do agree that is a good idea and I will try, but I 
wouldn't have the resources to fix the problem even if I found one.
I've put together a *productivity suite*, not a distribution,
and the last thing I want to do is muck around with the build internals
of each program that I'm using.

> Also, note that you don't need a chroot environment to
> build against a different glibc than your system.

of course, but unless you want to build everything static, you're 
at the mercy of LD_LIBRARY_PATH which will inevitably break either
your executables or the system executables depending on which comes
first.

I suppose I could fix it so that /etc/ld.so.conf does all the heavy 
lifting, get rid of LD_LIBRARY_PATH altogether and install
a custom ld.so.conf every time I build glibc. 

Although if I did that I'd *still* be vulnerable if the LD_LIBRARY_PATH 
got defined inadvertantly, by either system wrapper script or other process.





Hmm. perhaps the file /etc/ld.so.preload could be modified to take
directories as well as files? That way, I could simply 
install the glibc libraries into a special directory:

	<prefix>/libc

and then add that entry to /etc/ld.so.preload so they always came first
outside of LD_LIBRARY_PATH? Its not quite as flexible as the relative path
solution, but at least then you could guarantee that the right ld.so 
and libc.so were wedded together...


Ed