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

[Edward Peschko <esp5@pge.com>]

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