multiple glibcs

["GMANE" <spam at blazemail dot com>]

Recently I have been in the process of updating glibc, as there are numerous
applications out there requring a newer version than what I have. I run
debian 3.0r1 which has glibc 2.2.5. I try to avoid updating my entire
distro, as i'm running off of a 56k and doing such would take much time, so
i've dwelved into this and have found some odd things that i'm curious
about.

First, after I finaly got glibc 2.3.3 installed, which took numerous patches
and a newer gcc, I tried to do a normal install to /usr. Everything worked
out fine except I got a few Symbol errors on boot:

Symbol 'sys_siglist' has different size in shared object
Symbol 'sys_errlist' has different size in shared object

and things that use procps such as 'w' and 'ps' report an odd finding:

Unknown HZ value (90) Assume 100.

--

I imagine a few of these errors could be worked around by updating the
libraries they use (procps, etc) to comply with 2.3.3, but that's realy a
pain. 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, which isn't a problem since
ldconfig knows that the glibc.so.6 should be used in /oldglibc, only problem
is it doesn't know it should also use the ld-linux.so.2 in /glibc and the
new ld-linux.so.2 doesn't seem to be compatible with the older one (and vise
versa), I get errors when using the newer with an older glibc.so.6, that a
symbol such as GLIBC_2.2.3 is not found. When using the older ld-linux.so.2
with a newer glibc.so.6, I get errors that something to the sort of
_GLIBC_PRIVATE ? is not found.
So next I tried keeping the old glibc in /lib and installing the new one in
/usr/local, the only problem I found here is that for some reason when glibc
is configured for /usr/local, the new produced ldconfig thinks /usr/local is
it's root and won't ldconfig things in /lib and /usr/lib even if they are
given in /usr/local/etc/ld.so.conf or the command line. What I was hoping to
do is just compile the new stuff that needed the new glibc
with -Xlinker --dynamic-linker /usr/local/include/ld-linux.so.2 which
*would* technicly work well, except then since the new ld-linux.so.2 doesn't
know anything about /lib and /usr/lib, I would have to update all libraries
and place them in /usr/local/....
Last but not least, I built glibc with a prefix of /usr and reconfigured to
install at /usr/local, this worked out good, ld-linux.so.2 of the new glibc
knew about all the other libs in /lib and /usr/lib, so now I could just
compile things that wanted the new glibc with the linker in the new glibc
folder, and that linker would know about other libraries too (ncurses blah
etc). That's if I could figure out how to tell gcc to use not just the new
linker but the new libraries too. I tried -L/usr/local/lib which should make
the linker (or so I thought) look for glibc in /usr/local/lib before /lib,
but no, the linker in /usr/local/lib looked for glibc in /lib :/

What i'd like to know is the easiest way to go about this where I have to
update the least libraries.
Any responses/suggestions are welcome.

--Dan Biggle