Check it is actually needed
Firstly check the python application as it could be out of date and is probably misreading the glibc version. CentOS shows the base version as installed and is patched to keep up with changes and it could just be a case of fixing the version that is being looked for in the code as a quick fix, but if the application is being actively developed you need to let the developers know or fork it for yourself if you can.
An up to date glibc on CentOS 7 should be 2.17-196.el7_4.2
If it is needed, Containerise
If it's absolutely necessary to run this application, the official RHEL approach would be to containerize, but you would still need to provide a working glibc, which wouldn't be possible with stock CentOS 7.
As a last resort, install glibc in a nonstandard location
If this isn't viable, and as an absolute last resort, it is possible to install a newer version of glibc than 2.18 as that is 9 years old now and glibc has been updated for several vulnerabilities and I'm not sure off the top of my head if it will build with the version of make in CentOS 7, but any newer version should work as follows:
- This can potentially affect the functionality of your computer so make sure you know what you are doing
You can build the version of glibc you require elsewhere on your server and add it to LD_LIBRARY_PATH for the application. Note this must only be done for the application only.
wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
tar zxvf glibc-2.18.tar.gz
cd glibc-2.18
mkdir build
cd build
../configure --prefix=/opt/glibc-2.18
make -j4
sudo make install
Then to run a binary you need to use patchelf to update its interpreter
patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 program_you_are_running
And you need to enable it to find the new glibc library, either by
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib
Or you can use patchelf to update the binary's rpath (you can combine this with the previous pathelf command)
patchelf --set-rpath /opt/glibc-2.18/lib:/usr/lib64 program_you_are_running
If you change LD_LIBRARY_PATH don't export it for the whole system because all the binaries unmodified by patchelf will segfault.
/opt is the standard place to install third-party applications and libraries but you can use any path away from the system paths.
I am getting an error on CentOS 7 when trying to perform a yum update.
It's a small LAMP server. apache, php 7, mariadb.
When I run yum update, I get the following error that I am hoping someone can help resolve.
Error: Package: glibc-devel-2.17-324.el7_9.x86_64 (@updates)
Requires: glibc-headers = 2.17-324.el7_9
Removing: glibc-headers-2.17-324.el7_9.x86_64 (@updates)
glibc-headers = 2.17-324.el7_9
Updated By: glibc-headers-2.17-326.el7_9.x86_64 (updates)
glibc-headers = 2.17-326.el7_9
Available: glibc-headers-2.17-317.el7.x86_64 (base)
glibc-headers = 2.17-317.el7
Available: glibc-headers-2.17-322.el7_9.x86_64 (updates)
glibc-headers = 2.17-322.el7_9
Available: glibc-headers-2.17-323.el7_9.x86_64 (updates)
glibc-headers = 2.17-323.el7_9
Available: glibc-headers-2.17-325.el7_9.x86_64 (updates)
glibc-headers = 2.17-325.el7_9
cat /etc/*elease
CentOS Linux release 7.9.2009 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
CPE_NAME="cpe:/o:centos:centos:7"
CentOS Linux release 7.9.2009 (Core)
[root@www scripts]# sudo yum -y update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.xenyth.net
* elrepo: linux-mirrors.fnal.gov
* epel: mirror.dst.ca
* extras: mirror.xenyth.net
* remi-safe: cdn.centos.no
* updates: mirror.xenyth.net
Resolving Dependencies
--> Running transaction check
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be updated
---> Package apr-util.x86_64 0:1.5.2-6.el7_9.1 will be an update
---> Package bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.9 will be updated
---> Package bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.14 will be an update
---> Package ca-certificates.noarch 0:2020.2.41-70.0.el7_8 will be updated
---> Package ca-certificates.noarch 0:2022.2.54-74.el7_9 will be an update
---> Package cronie.x86_64 0:1.4.11-23.el7 will be updated
---> Package cronie.x86_64 0:1.4.11-24.el7_9 will be updated
---> Package cronie.x86_64 0:1.4.11-25.el7_9 will be an update
---> Package cronie-anacron.x86_64 0:1.4.11-24.el7_9 will be updated
---> Package cronie-anacron.x86_64 0:1.4.11-25.el7_9 will be an update
---> Package diffutils.x86_64 0:3.3-5.el7 will be updated
---> Package diffutils.x86_64 0:3.3-6.el7_9 will be an update
---> Package elrepo-release.noarch 0:7.0-5.el7.elrepo will be updated
---> Package elrepo-release.noarch 0:7.0-6.el7.elrepo will be an update
---> Package expat.x86_64 0:2.1.0-14.el7_9 will be updated
---> Package expat.x86_64 0:2.1.0-15.el7_9 will be an update
---> Package glibc-headers.x86_64 0:2.17-324.el7_9 will be updated
--> Processing Dependency: glibc-headers = 2.17-324.el7_9 for package: glibc-devel-2.17-324.el7_9.x86_64
---> Package glibc-headers.x86_64 0:2.17-326.el7_9 will be an update
---> Package grub2.x86_64 1:2.02-0.87.el7.9 will be updated
---> Package grub2.x86_64 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-common.noarch 1:2.02-0.87.el7.9 will be updated
---> Package grub2-common.noarch 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-pc.x86_64 1:2.02-0.87.el7.9 will be updated
---> Package grub2-pc.x86_64 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-pc-modules.noarch 1:2.02-0.87.el7.9 will be updated
---> Package grub2-pc-modules.noarch 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-tools.x86_64 1:2.02-0.87.el7.centos.6 will be updated
---> Package grub2-tools.x86_64 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-tools-extra.x86_64 1:2.02-0.87.el7.9 will be updated
---> Package grub2-tools-extra.x86_64 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package grub2-tools-minimal.x86_64 1:2.02-0.87.el7.9 will be updated
---> Package grub2-tools-minimal.x86_64 1:2.02-0.87.0.2.el7.centos.11 will be an update
---> Package httpd.x86_64 0:2.4.6-97.el7.centos will be updated
---> Package httpd.x86_64 0:2.4.6-99.el7.centos.1 will be an update
---> Package httpd-tools.x86_64 0:2.4.6-97.el7.centos.5 will be updated
---> Package httpd-tools.x86_64 0:2.4.6-99.el7.centos.1 will be an update
---> Package kernel.x86_64 0:3.10.0-1160.95.1.el7 will be installed
---> Package kernel-headers.x86_64 0:3.10.0-1160.66.1.el7 will be updated
---> Package kernel-headers.x86_64 0:3.10.0-1160.95.1.el7 will be an update
---> Package kernel-tools.x86_64 0:3.10.0-1160.66.1.el7 will be updated
---> Package kernel-tools.x86_64 0:3.10.0-1160.95.1.el7 will be an update
---> Package kernel-tools-libs.x86_64 0:3.10.0-1160.66.1.el7 will be updated
---> Package kernel-tools-libs.x86_64 0:3.10.0-1160.95.1.el7 will be an update
---> Package kmod-ixgbe.x86_64 0:5.8.1-1.el7_9.elrepo will be updated
---> Package kmod-ixgbe.x86_64 0:5.8.1-2.el7_9.elrepo will be updated
---> Package kmod-ixgbe.x86_64 0:5.12.5-1.el7_9.elrepo will be updated
---> Package kmod-ixgbe.x86_64 0:5.12.5-2.el7_9.elrepo will be an update
---> Package kpartx.x86_64 0:0.4.9-135.el7_9 will be updated
---> Package kpartx.x86_64 0:0.4.9-136.el7_9 will be an update
---> Package krb5-devel.x86_64 0:1.15.1-51.el7_9 will be updated
---> Package krb5-devel.x86_64 0:1.15.1-55.el7_9 will be an update
---> Package krb5-libs.x86_64 0:1.15.1-51.el7_9 will be updated
---> Package krb5-libs.x86_64 0:1.15.1-55.el7_9 will be an update
---> Package libXpm.x86_64 0:3.5.12-1.el7 will be updated
---> Package libXpm.x86_64 0:3.5.12-2.el7_9 will be an update
---> Package libkadm5.x86_64 0:1.15.1-51.el7_9 will be updated
---> Package libkadm5.x86_64 0:1.15.1-55.el7_9 will be an update
---> Package microcode_ctl.x86_64 2:2.1-73.11.el7_9 will be updated
---> Package microcode_ctl.x86_64 2:2.1-73.13.el7_9 will be updated
---> Package microcode_ctl.x86_64 2:2.1-73.16.el7_9 will be an update
---> Package mod_ssl.x86_64 1:2.4.6-97.el7.centos.5 will be updated
---> Package mod_ssl.x86_64 1:2.4.6-99.el7.centos.1 will be an update
---> Package nspr.x86_64 0:4.32.0-1.el7_9 will be updated
---> Package nspr.x86_64 0:4.34.0-3.1.el7_9 will be an update
---> Package nss.x86_64 0:3.67.0-4.el7_9 will be updated
---> Package nss.x86_64 0:3.79.0-5.el7_9 will be an update
---> Package nss-pem.x86_64 0:1.0.3-7.el7 will be updated
---> Package nss-pem.x86_64 0:1.0.3-7.el7_9.1 will be an update
---> Package nss-softokn.x86_64 0:3.67.0-3.el7_9 will be updated
---> Package nss-softokn.x86_64 0:3.79.0-4.el7_9 will be an update
---> Package nss-softokn-freebl.x86_64 0:3.67.0-3.el7_9 will be updated
---> Package nss-softokn-freebl.x86_64 0:3.79.0-4.el7_9 will be an update
---> Package nss-sysinit.x86_64 0:3.67.0-4.el7_9 will be updated
---> Package nss-sysinit.x86_64 0:3.79.0-5.el7_9 will be an update
---> Package nss-tools.x86_64 0:3.67.0-4.el7_9 will be updated
---> Package nss-tools.x86_64 0:3.79.0-5.el7_9 will be an update
---> Package nss-util.x86_64 0:3.67.0-1.el7_9 will be updated
---> Package nss-util.x86_64 0:3.79.0-1.el7_9 will be an update
---> Package openssh.x86_64 0:7.4p1-21.el7 will be updated
---> Package openssh.x86_64 0:7.4p1-23.el7_9 will be an update
---> Package openssh-clients.x86_64 0:7.4p1-22.el7_9 will be updated
---> Package openssh-clients.x86_64 0:7.4p1-23.el7_9 will be an update
---> Package openssh-server.x86_64 0:7.4p1-21.el7 will be updated
---> Package openssh-server.x86_64 0:7.4p1-23.el7_9 will be an update
---> Package openssl.x86_64 1:1.0.2k-25.el7_9 will be updated
---> Package openssl.x86_64 1:1.0.2k-26.el7_9 will be an update
---> Package openssl-devel.x86_64 1:1.0.2k-25.el7_9 will be updated
---> Package openssl-devel.x86_64 1:1.0.2k-26.el7_9 will be an update
---> Package openssl-libs.x86_64 1:1.0.2k-25.el7_9 will be updated
---> Package openssl-libs.x86_64 1:1.0.2k-26.el7_9 will be an update
---> Package polkit.x86_64 0:0.112-26.el7 will be updated
---> Package polkit.x86_64 0:0.112-26.el7_9.1 will be an update
---> Package python.x86_64 0:2.7.5-90.el7 will be updated
---> Package python.x86_64 0:2.7.5-93.el7_9 will be an update
---> Package python-libs.x86_64 0:2.7.5-90.el7 will be updated
---> Package python-libs.x86_64 0:2.7.5-93.el7_9 will be an update
---> Package python-perf.x86_64 0:3.10.0-1160.66.1.el7 will be updated
---> Package python-perf.x86_64 0:3.10.0-1160.95.1.el7 will be an update
---> Package remi-release.noarch 0:7.9-3.el7.remi will be updated
---> Package remi-release.noarch 0:7.9-5.el7.remi will be an update
---> Package rsync.x86_64 0:3.1.2-10.el7 will be updated
---> Package rsync.x86_64 0:3.1.2-12.el7_9 will be an update
---> Package rsyslog.x86_64 0:8.24.0-57.el7_9.1 will be updated
---> Package rsyslog.x86_64 0:8.24.0-57.el7_9.2 will be updated
---> Package rsyslog.x86_64 0:8.24.0-57.el7_9.3 will be an update
---> Package s3cmd.noarch 0:2.2.0-1.el7 will be updated
---> Package s3cmd.noarch 0:2.3.0-4.el7 will be an update
---> Package sudo.x86_64 0:1.8.23-10.el7_9.2 will be updated
---> Package sudo.x86_64 0:1.8.23-10.el7_9.3 will be an update
---> Package systemd.x86_64 0:219-78.el7_9.3 will be updated
---> Package systemd.x86_64 0:219-78.el7_9.7 will be an update
---> Package systemd-libs.x86_64 0:219-78.el7_9.5 will be updated
---> Package systemd-libs.x86_64 0:219-78.el7_9.7 will be an update
---> Package systemd-sysv.x86_64 0:219-78.el7_9.5 will be updated
---> Package systemd-sysv.x86_64 0:219-78.el7_9.7 will be an update
---> Package tuned.noarch 0:2.11.0-11.el7_9 will be updated
---> Package tuned.noarch 0:2.11.0-12.el7_9 will be an update
---> Package tzdata.noarch 0:2022a-1.el7 will be updated
---> Package tzdata.noarch 0:2023c-1.el7 will be an update
---> Package xz.x86_64 0:5.2.2-1.el7 will be updated
---> Package xz.x86_64 0:5.2.2-2.el7_9 will be an update
---> Package xz-devel.x86_64 0:5.2.2-1.el7 will be updated
---> Package xz-devel.x86_64 0:5.2.2-2.el7_9 will be an update
---> Package xz-libs.x86_64 0:5.2.2-1.el7 will be updated
---> Package xz-libs.x86_64 0:5.2.2-2.el7_9 will be an update
---> Package zlib.x86_64 0:1.2.7-20.el7_9 will be updated
---> Package zlib.x86_64 0:1.2.7-21.el7_9 will be an update
---> Package zlib-devel.x86_64 0:1.2.7-20.el7_9 will be updated
---> Package zlib-devel.x86_64 0:1.2.7-21.el7_9 will be an update
--> Finished Dependency Resolution
--> Running transaction check
---> Package glibc-headers.x86_64 0:2.17-324.el7_9 will be updated
--> Processing Dependency: glibc-headers = 2.17-324.el7_9 for package: glibc-devel-2.17-324.el7_9.x86_64
---> Package kernel.x86_64 0:3.10.0-1160.el7 will be erased
--> Finished Dependency Resolution
Error: Package: glibc-devel-2.17-324.el7_9.x86_64 (@updates)
Requires: glibc-headers = 2.17-324.el7_9
Removing: glibc-headers-2.17-324.el7_9.x86_64 (@updates)
glibc-headers = 2.17-324.el7_9
Updated By: glibc-headers-2.17-326.el7_9.x86_64 (updates)
glibc-headers = 2.17-326.el7_9
Available: glibc-headers-2.17-317.el7.x86_64 (base)
glibc-headers = 2.17-317.el7
Available: glibc-headers-2.17-322.el7_9.x86_64 (updates)
glibc-headers = 2.17-322.el7_9
Available: glibc-headers-2.17-323.el7_9.x86_64 (updates)
glibc-headers = 2.17-323.el7_9
Available: glibc-headers-2.17-325.el7_9.x86_64 (updates)
glibc-headers = 2.17-325.el7_9
You could try using --skip-broken to work around the problem
** Found 23 pre-existing rpmdb problem(s), 'yum check' output follows:
binutils-2.27-44.base.el7_9.1.x86_64 is a duplicate with binutils-2.27-44.base.el7.x86_64
cronie-1.4.11-24.el7_9.x86_64 is a duplicate with cronie-1.4.11-23.el7.x86_64
glibc-devel-2.17-324.el7_9.x86_64 has missing requires of glibc = ('0', '2.17', '324.el7_9')
glibc-devel-2.17-325.el7_9.x86_64 is a duplicate with glibc-devel-2.17-324.el7_9.x86_64
glibc-devel-2.17-325.el7_9.x86_64 has missing requires of glibc = ('0', '2.17', '325.el7_9')
glibc-devel-2.17-325.el7_9.x86_64 has missing requires of glibc-headers = ('0', '2.17', '325.el7_9')
glibc-devel-2.17-326.el7_9.x86_64 is a duplicate with glibc-devel-2.17-325.el7_9.x86_64
glibc-devel-2.17-326.el7_9.x86_64 has missing requires of glibc-headers = ('0', '2.17', '326.el7_9')
glibc-headers-2.17-324.el7_9.x86_64 has missing requires of glibc = ('0', '2.17', '324.el7_9')
1:grub2-pc-2.02-0.87.el7.9.x86_64 has missing requires of grub2-tools = ('1', '2.02', '0.87.el7.9')
1:grub2-tools-2.02-0.87.el7.centos.6.x86_64 has missing requires of grub2-common = ('1', '2.02', '0.87.el7.centos.6')
1:grub2-tools-2.02-0.87.el7.centos.6.x86_64 has missing requires of grub2-tools-minimal = ('1', '2.02', '0.87.el7.centos.6')
1:grub2-tools-extra-2.02-0.87.el7.9.x86_64 has missing requires of grub2-tools = ('1', '2.02', '0.87.el7.9')
gzip-1.5-11.el7_9.x86_64 is a duplicate with gzip-1.5-10.el7.x86_64
httpd-2.4.6-97.el7.centos.x86_64 has missing requires of httpd-tools = ('0', '2.4.6', '97.el7.centos')
kmod-ixgbe-5.8.1-2.el7_9.elrepo.x86_64 is a duplicate with kmod-ixgbe-5.8.1-1.el7_9.elrepo.x86_64
kmod-ixgbe-5.12.5-1.el7_9.elrepo.x86_64 is a duplicate with kmod-ixgbe-5.8.1-2.el7_9.elrepo.x86_64
2:microcode_ctl-2.1-73.13.el7_9.x86_64 is a duplicate with 2:microcode_ctl-2.1-73.11.el7_9.x86_64
1:mod_ssl-2.4.6-97.el7.centos.5.x86_64 has missing requires of httpd = ('0', '2.4.6', '97.el7.centos.5')
openssh-clients-7.4p1-22.el7_9.x86_64 has missing requires of openssh = ('0', '7.4p1', '22.el7_9')
rsyslog-8.24.0-57.el7_9.2.x86_64 is a duplicate with rsyslog-8.24.0-57.el7_9.1.x86_64
systemd-219-78.el7_9.3.x86_64 has missing requires of systemd-libs = ('0', '219', '78.el7_9.3')
systemd-sysv-219-78.el7_9.5.x86_64 has missing requires of systemd = ('0', '219', '78.el7_9.5')package management - Cannot update glibc on CentOS 7 - Unix & Linux Stack Exchange
centos - Unable to update glibc to the latest version - Unix & Linux Stack Exchange
centos7 - Upgrade glibc 2.17 to 2.19+ on CentOS 7 - Stack Overflow
centos7 - rpm glibc Centos 7 - Stack Overflow
Check it is actually needed
Firstly check the python application as it could be out of date and is probably misreading the glibc version. CentOS shows the base version as installed and is patched to keep up with changes and it could just be a case of fixing the version that is being looked for in the code as a quick fix, but if the application is being actively developed you need to let the developers know or fork it for yourself if you can.
An up to date glibc on CentOS 7 should be 2.17-196.el7_4.2
If it is needed, Containerise
If it's absolutely necessary to run this application, the official RHEL approach would be to containerize, but you would still need to provide a working glibc, which wouldn't be possible with stock CentOS 7.
As a last resort, install glibc in a nonstandard location
If this isn't viable, and as an absolute last resort, it is possible to install a newer version of glibc than 2.18 as that is 9 years old now and glibc has been updated for several vulnerabilities and I'm not sure off the top of my head if it will build with the version of make in CentOS 7, but any newer version should work as follows:
- This can potentially affect the functionality of your computer so make sure you know what you are doing
You can build the version of glibc you require elsewhere on your server and add it to LD_LIBRARY_PATH for the application. Note this must only be done for the application only.
wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
tar zxvf glibc-2.18.tar.gz
cd glibc-2.18
mkdir build
cd build
../configure --prefix=/opt/glibc-2.18
make -j4
sudo make install
Then to run a binary you need to use patchelf to update its interpreter
patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 program_you_are_running
And you need to enable it to find the new glibc library, either by
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib
Or you can use patchelf to update the binary's rpath (you can combine this with the previous pathelf command)
patchelf --set-rpath /opt/glibc-2.18/lib:/usr/lib64 program_you_are_running
If you change LD_LIBRARY_PATH don't export it for the whole system because all the binaries unmodified by patchelf will segfault.
/opt is the standard place to install third-party applications and libraries but you can use any path away from the system paths.
In the end,I did not have to upgrade GLIBC. The gdc-client tool I downloaded through R seemed to be for Ubuntu and not CentOS, though I did it on CentOS 7. I then downloaded the gdc-client for CentOS and it worked fine.
You need to download the following 4 packages from a mirror:
- glibc-2.17-55.el7.i686.rpm
- glibc-2.17-55.el7.x86_64.rpm
- glibc-common-2.17-55.el7.x86_64.rpm
- glibc-headers-2.17-55.el7.x86_64.rpm
After doing so, issue a rpm -ivh glibc-*. If that fails, download:
- glibc-devel-2.17-55.el7.i686.rpm
- glibc-devel-2.17-55.el7.x86_64.rpm
and reissue the command again. After getting glibc updated, issue a yum update to resolve any new dependencies.
If you have glibc 2.12 installed, you do NOT have CentOS7; you're on CentOS6. While there's been a lot of grief about the locking of major/minor versions after distro release - it's for stability, testing and certification; you'll learn the value later - the version you're looking at should not exist under an up-to-date centos7.
Update your CentOS7, do a yum install of apr (apr-devel too?) and you're done.
If you DO have CentOS6, apr-1.3.9-5.el6_2.x86_64 requires glibc-2.12 . Yum install will get you what you need here, as well.
In general
- Don't mix RPMs from alient repositories: you're looking for pain.
- Don't mix RPMs from two different distro releases -- they're designed to work together, and tested so.
- if it's suddenly hard, or there are strange messages, there's a really good chance you're doing something you should not.
- Dependency Hell [tm] is self-inflicted. No exceptions.
I worked at a distro; not in Support but adjacent to it. #4 is a well-tested theory.
You can upgrade all the packages at the same time, using a command like this one:
sudo rpm -U glibc-2.17-317.el7.x86_64.rpm glibc-common-2.17-317.el7.x86_64.rpm
Or you can use yum update, like this:
sudo yum update --disablerepo="*" *.rpm
This has the advantage that packages not installed are not automatically installed by the upgrade (unless dependencies require it). --disablerepo="*" ensures that yum update does not try to download anything.
jlehtone in forums.centos.org solved my situation. I just needed to write
sudo rpm -i glibc-2.17-292.el7.i686.rpm nss-softokn-freebl-3.44.0-8.el7_7.i686.rpm nspr-4.25.0-2.el7_9.i686.rpm nss-util-3.53.1-1.el7_9.i686.rpm
Link to forums.centos.org
You cannot update glibc on Centos 6 safely. However you can install 2.14 alongside 2.12 easily, then use it to compile projects etc. Here is how:
mkdir ~/glibc_install; cd ~/glibc_install
wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
tar zxvf glibc-2.14.tar.gz
cd glibc-2.14
mkdir build
cd build
../configure --prefix=/opt/glibc-2.14
make -j4
sudo make install
export LD_LIBRARY_PATH="/opt/glibc-2.14/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
To install glibc 2.14 in parallel, add the configure prefix:
tar zxvf glibc-2.14.tar.gz
cd glibc-2.14
mkdir build
cd build
../configure --prefix=/opt/glibc-2.14
make -j4
make install
Following this process, you'll be able to build 2.14 but you will need to tell the compiler where to look for glibc.
Below are the ways you can expose the glibc to your program.
LD_LIBRARY_PATH=/opt/glibc-2.14/lib
export LD_LIBRARY_PATH.
The library is exposed during your current login session.
You can permanently link your new glibc version like so, but please read the WARNING below:
ln -sf /opt/glibc-2.14/glibc-2.14.so /lib/libc.so.6.
Since libc.so.6 is just a symbolic link. Executing the above command will make the link point towards the new glibc library. However this step is not recommended since there are many programs in Linux which depend on older versions and will stop working.