This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)
- From: Edward Peschko <esp5 at pge dot com>
- To: Dan Kegel <dank at kegel dot com>
- Cc: ian at airs dot com, Joe dot Buck at synopsys dot COM, alan at lxorguk dot ukuu dot org dot uk, libc-alpha at sources dot redhat dot com, binutils at sources dot redhat dot com
- Date: Fri, 28 Jan 2005 12:40:07 -0800
- Subject: modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)
- References: <20050127041429.GA16277@venus> <41F878CC.8000502@kegel.com> <20050127211101.GD16277@venus> <41F98CBB.4010902@kegel.com>
> 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