On Mon, Mar 30, 2015 at 10:47:24PM -0400, Alfred von Campe wrote: > Forget I ever said I wanted to replace glibc. Assume it’s a different > library or application. Except libc is not just like any other library. Unless you're going to recompile the software, the location of the ld loader is hard-coded to your existing ld-linux.so.2, and even if you had a parallel version of glibc elsewhere, it'll try to load the wrong ld-linux and throw symbol errors. You can use LD_PRELOAD to get around this, but you can run into other dependency problems when other OS-packaged libraries are used by along with LD_PRELOAD. If this were some non-core library, sure, its possible to build and package it for an alternative directory, and either hard code rpath when compiling or use environment variables to use it (which we do quite often with environment modules (http://modules.sourceforge.net/). glibc just happens to be much more complex, which is why its easier to just use a newer version of CentOS either in a VM or a chroot. -- Jonathan Billings <billings at negate.org>