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@xxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
