Alfred von Campe
2015-Mar-31 02:47 UTC
[CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
> On Mar 30, 2015, at 17:24, Patrick Flaherty <pflaherty at wsi.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. 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. Alfred
Jonathan Billings
2015-Mar-31 12:41 UTC
[CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
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>
Les Mikesell
2015-Mar-31 16:12 UTC
[CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
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
Jim Perrin
2015-Mar-31 16:21 UTC
[CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
On 03/31/2015 11:12 AM, Les Mikesell wrote:> 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?Yes, you could address this with docker quite easily, depending on the app. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77
Possibly Parallel Threads
- Building a newer glibc RPM for CentOS 6 and installing into an alternate path
- Building a newer glibc RPM for CentOS 6 and installing into an alternate path
- Building a newer glibc RPM for CentOS 6 and installing into an alternate path
- Building a newer glibc RPM for CentOS 6 and installing into an alternate path
- Building a newer glibc RPM for CentOS 6 and installing into an alternate path