* modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)
[not found] ` <41F98CBB.4010902@kegel.com>
@ 2005-01-28 20:48 ` Edward Peschko
2005-01-28 21:04 ` Joe Buck
0 siblings, 1 reply; 3+ messages in thread
From: Edward Peschko @ 2005-01-28 20:48 UTC (permalink / raw)
To: Dan Kegel; +Cc: ian, Joe.Buck, alan, libc-alpha, binutils
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)
2005-01-28 20:48 ` modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking) Edward Peschko
@ 2005-01-28 21:04 ` Joe Buck
2005-01-28 21:22 ` Edward Peschko
0 siblings, 1 reply; 3+ messages in thread
From: Joe Buck @ 2005-01-28 21:04 UTC (permalink / raw)
To: Edward Peschko; +Cc: Dan Kegel, ian, alan, libc-alpha, binutils
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").
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking)
2005-01-28 21:04 ` Joe Buck
@ 2005-01-28 21:22 ` Edward Peschko
0 siblings, 0 replies; 3+ messages in thread
From: Edward Peschko @ 2005-01-28 21:22 UTC (permalink / raw)
To: Joe Buck; +Cc: Dan Kegel, ian, alan, libc-alpha, binutils
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-01-28 21:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20050127041429.GA16277@venus>
[not found] ` <41F878CC.8000502@kegel.com>
[not found] ` <20050127211101.GD16277@venus>
[not found] ` <41F98CBB.4010902@kegel.com>
2005-01-28 20:48 ` modified /etc/ld.so.preload (was: forestalling GNU incompatibility - proposal for binary relative dynamic linking) Edward Peschko
2005-01-28 21:04 ` Joe Buck
2005-01-28 21:22 ` Edward Peschko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).