On Mon, Mar 30, 2015 at 9:47 PM, Alfred von Campe alfred@von-campe.com wrote:
Tell your vendor you want a centos 6 version of the library, it's really not a huge ask, esp if you are paying them. If they say no, do a new install of centos 7 and run it on a different box. It's the only reasonable thing to do, and if you do anything else and make anyone else support it, you are a bad person.
I’m not quite ready to move to CentOS 7 yet. I would have to upgrade about 80 desktops, a couple of dozen VMs, and a handful of servers. That’s after some extensive testing to make sure all our applications and cross compilers run on CentOS 7. I realize the dependency hell a newer version of glib would cause, but I want to at least try it.
Isn't this the problem that docker was invented to solve?
Forget I ever said I wanted to replace glibc. Assume it’s a different library or application. I guess what I really need to know is how to rebuild a source RPM after modifying the installation path. A quick peek at the spec file for glibc did not reveal any easy options, but then again I don’t really speak the RPM spec file language.
If you build a stock rpm - or just grab an existing binary rpm you can install the files in a different location with:
cd /some/location rpm2cpio some_package.rpm | cpio -idmv --no-absolute-filenames (that's sort of routine for debugging cores from a different system....) But I'd expect some close coupling between the compiler and glibc too, so you probably can't compile a new version either without installing newer tools too.
What kind of application is this? Would it be practical to run it remotely via ssh or a remote X window so you would only need one or a few systems capable of running it?