* 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).