CentOS - Mar 2015 - Building a newer glibc RPM for CentOS 6 and installing into an alternate path

We have a third party shared library from a vendor that requires glib 2.15 or
newer.  We are using CentOS 6.6 which comes with glibc 2.12, and I know it can?t
be replaced as it?s an integral part of the OS.

However, is it possible to build a glib 2.15 RPM from source to be installed in
/opt/centos (or somewhere else other than /usr/lib) so that I can link the one
application that requires the third party shared library with this version of
glib?  If so, does anyone have instructions on how to build such an RPM, or
better yet, has already build such an RPM?

Thanks,
Alfred

Alfred von Campe wrote:
> We have a third party shared library from a vendor that requires glib 2.15
or newer.
> We are using CentOS 6.6 which comes with glibc 2.12, and I know it can?t be
replaced
> as it?s an integral part of the OS.
>
> However, is it possible to build a glib 2.15 RPM from source to be
installed in /opt/centos
> (or somewhere else other than /usr/lib) so that I can link the one
application that requires
> the third party shared library with this version of glib?  If so, does
anyone have instructions
> on how to build such an RPM, or better yet, has already build such an RPM?
I don't think it is as straight forward as that ...

I did something like this _many_ years ago (to get a RedHat 9 binary to run on
RedHat 7.2) - which involved copying the /lib tree from a 'newer' OS
install to a separate tree - and then using the ld-linux.so.2 binary from the
newer tree to load the binary - and if memory serves me right, something like
(for a 32 bit binary, as they were then):

 /path/to/newer/glibc/lib/ld-linux.so.2 --library-path /path/to/newer/glibc/lib
/path/to/binary

You will probably have problems if the binary uses dlopen() to load other shared
libs ...

I have no idea if this is still valid - as the last time I tried this was over
10 years ago ...

James Pearson

On Mon, Mar 30, 2015 at 11:58 AM, Alfred von Campe <alfred at
von-campe.com>
wrote:
> We have a third party shared library from a vendor that requires glib 2.15
> or newer.  We are using CentOS 6.6 which comes with glibc 2.12, and I know
> it can't be replaced as it's an integral part of the OS.
>
> However, is it possible to build a glib 2.15 RPM from source to be
> installed in /opt/centos (or somewhere else other than /usr/lib) so that I
> can link the one application that requires the third party shared library
> with this version of glib?  If so, does anyone have instructions on how to
> build such an RPM, or better yet, has already build such an RPM?
>
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.

If it's a lack of hardware, CentOS 6 has virtualization built in, turn the
server into a VM host and make a centos 7 guest. A one off VM is awful, but
better than any other hatchet job you may come up with.

Don't do these. For real. They are super fun exercises, but much like linux
from scratch, they are painful, hard to maintain, and implementing them
would get you removed from my development team.

Try following https://gist.github.com/ldx/9116170 but do a cent7 chroot
install instead. That would probably work, and you'd be able to patch both
systems with regular yum updates. I've done something similar on debian
boxes in the past and it surprisingly worked. This is the least bad of the
terrible options I've provided (assuming it works).

Install centos 7 in a vm. Get your app over there and see if it runs. If it
does, run ldd on the box and copy all the dependencies to a directory on
your cent6 box. You will have to run ldd on all the libraries you copy as
well to get their dependencies. You will want to script that. Actually
don't script it. You will give up with in 20 libraries. If you do get all
the dependencies, you can override the library path by running your app
like LD_LIBRARY_PATH=/yourlibrarydirectory yourapp Congrats, you have a
total point-in-time one off, and you should feel bad about yourself.

If you google steam and centos 6 you will find plenty of people who have
update glibc to a newer version with zero ramifications. Those people are
tempting sirens luring you to the rocks. Just know you will never get
another security update to glibc ever again, and let me hammer this home,
if you make this machine someone else's responsibility, you will end up in
a very special circle of hell (some where near carrot top and the "can you
hear me now" guy).

> 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