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

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

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

[Joe Buck]

On Fri, Jan 28, 2005 at 12:40:07PM -0800, Edward Peschko wrote:
> 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.

[ offtopic ]

Being "at the mercy of LD_LIBRARY_PATH" is a feature, which if you break
will stop a number of apps, like valgrind and ltrace, from working.
They rely, for correct function, on the ability to intercept calls to
the C library (that is, to "call the wrong glibc").

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

[Edward Peschko]

On Fri, Jan 28, 2005 at 01:03:58PM -0800, Joe Buck wrote:
> On Fri, Jan 28, 2005 at 12:40:07PM -0800, Edward Peschko wrote:
> > 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.
> 
> [ offtopic ]
> 
> Being "at the mercy of LD_LIBRARY_PATH" is a feature, which if you break
> will stop a number of apps, like valgrind and ltrace, from working.
> They rely, for correct function, on the ability to intercept calls to
> the C library (that is, to "call the wrong glibc").

good point..

then I really don't see anyway to do what I want to do without either
massively modifying the build infrastructure of what I am doing to make
everything either compile with the correct gcc flags, or providing
rpath-like functionality in LD_LIBRARY_PATH.

Either that or adding directories to /etc/ld.so.preload and statically 
compiling the exceptions: valgrind, ltrace, etc, versus the 'wrong libc'.

Or - maybe valgrind, et al, could use LD_PRELOAD (which also could be 
modified to accept directories) and then we could be at the mercy
of LD_PRELOAD instead?

Ed