On Mon, Mar 30, 2015 at 9:47 PM, Alfred von Campe <alfred at 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? -- Les Mikesell lesmikesell at gmail.com