This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: multiple glibcs
- From: Mike Hearn <mike at navi dot cx>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 07 Dec 2004 22:07:58 +0000
- Subject: Re: multiple glibcs
- References: <cp07te$him$1@sea.gmane.org>
On Sun, 05 Dec 2004 19:08:10 -0500, GMANE wrote:
> So instead I tried doing dual glibcs, with the new glibc being in /lib
> and the older one being in /oldglibc, it seems although that these programs
> where compiled to use the ld-linux.so.2 in /lib
You can use a specific linker by running it, eg:
/newglibc/ld-linux.so.2 /path/to/binary
The issue of newer binaries needing newer glibcs is a tricky one.
Typically this is because:
a) They are using new symbol versions. Unfortunately exactly what
changes between the different versions isn't documented anywhere
(or not that I can find) so developers can't make a decision about
whether it's OK to specifically use an older version in the same
of binary portability.
b) They are using thread local locales. This is a great feature that
isn't useful at all for desktop programs, but they get it anyway
via header rewriting.
You can compile software using a variety of techniques to allow it to run
on older glibcs but no shipping software is currently compiled in this way.
Sorry ... GNU/Linux just sucks over a 56k line due mostly to huge platform
instability in the upper levels (glibc itself is relatively stable).
thanks -mike