This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [ian@airs.com: Re: forestalling GNU incompatibility - proposalfor binary relative dynamic linking]
- From: Dan Kegel <dank at kegel dot com>
- To: Edward Peschko <esp5 at pge dot com>
- Cc: ian at airs dot com, Joe Buck <Joe dot Buck at synopsys dot COM>, alan at lxorguk dot ukuu dot org dot uk, libc-alpha at sources dot redhat dot com
- Date: Thu, 27 Jan 2005 16:52:11 -0800
- Subject: Re: [ian@airs.com: Re: forestalling GNU incompatibility - proposalfor binary relative dynamic linking]
- References: <20050127041429.GA16277@venus> <41F878CC.8000502@kegel.com> <20050127211101.GD16277@venus>
Edward Peschko wrote:
"A developer is compiling a large set of applications that he doesn't
control, and hence may or may not be LSB compliant. He cannot expect
the oldest version of glibc to apply because the applications may
depend on newer glibc features. He does not have root, so therefore
cannot develop in a chroot environment.
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?
Also, note that you don't need a chroot environment to
build against a different glibc than your system.
Furthermore, one of the things that he is doing is migrating from an older
version of glibc to a newer one, and wants both the freedom of doing
it without trashing his environment, and not having to rebuild his programs
from scratch to test versus two versions of glibc.
"
I'm confused; are you migrating your development workstation
to a newer glibc? If you're using cross-compilation techniques,
that shouldn't matter here.
However, it occurs to me that the patch alone would not be enough..
apparently the ld.so interface heeps changing, which makes it currently
impossible to use any system libraries unrelated to the current glibc.
My question is: why does this interface keep changing? Could it be
stabilized?
ld.so is part of glibc. glibc promises that newer ld.so's can run
programs linked against older glibc's. That's enough for most people.
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html