CentOS - Mar 2015 - 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

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>

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

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