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@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@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.
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?
On 03/31/2015 11:12 AM, Les Mikesell wrote:
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?
Yes, you could address this with docker quite easily, depending on the app.
On Mar 31, 2015, at 12:21, Jim Perrin jperrin@centos.org wrote:
Isn't this the problem that docker was invented to solve?
Yes, you could address this with docker quite easily, depending on the app.
Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a while. In the mean time, we’ve requested a CentOS 6 compatible .shared library from our vendor, and I’m keeping my fingers crossed while waiting for their reply.
Alfred
On Tue, Mar 31, 2015 at 12:43 PM, Alfred von Campe alfred@von-campe.com wrote:
On Mar 31, 2015, at 12:21, Jim Perrin jperrin@centos.org wrote:
Isn't this the problem that docker was invented to solve?
Yes, you could address this with docker quite easily, depending on the app.
Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a while. In the mean time, we’ve requested a CentOS 6 compatible .shared library from our vendor, and I’m keeping my fingers crossed while waiting for their reply.
What about remote exectution? You might even give it access to local files with x2go.
Les Mikesell wrote:
On Tue, Mar 31, 2015 at 12:43 PM, Alfred von Campe alfred@von-campe.com wrote:
On Mar 31, 2015, at 12:21, Jim Perrin jperrin@centos.org wrote:
Isn't this the problem that docker was invented to solve?
Yes, you could address this with docker quite easily, depending on the app.
Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a
while. <snip> I haven't really been following this thread closely, but would it be a dumb question to suggest installing the rpm with the relocate flag, and then use LD_LIBRARY_PATH?
mark
On Tue, Mar 31, 2015 at 1:21 PM, m.roth@5-cent.us wrote:
Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a
while.
<snip> I haven't really been following this thread closely, but would it be a dumb question to suggest installing the rpm with the relocate flag, and then use LD_LIBRARY_PATH?
It was mentioned earlier that LD_LIBRARY_PATH doesn't work with libc, but LD_PRELOAD should.. I tried unpacking a centos7 glibc rpm under /tmp/c7libs on a centos 6 box and trying to run a centos7 version of cat with:
LD_LIBRARY_PATH=/tmp/c7libs/lib64:$LD_LIBRARY_PATH LD_PRELOAD="/tmp/c7libs/lib64/ld-linux-x86-64.so.2 /tmp/c7libs/lib64/libc.so.6" /tmp/cat-7 /tmp/test
seems to work, but that's not a real demanding test...
-
Alfred von Campe -
James Pearson -
Jim Perrin -
Jonathan Billings -
Les Mikesell -
m.roth＠5-cent.us -
Patrick Flaherty