Previously, it was often called "libc. so.6: version 'glibc _ 2.14 & prime; not found "error message. The cause is that the current system installed GLIBC version is lower than the GLIBC version used for software compilation.
This is one of the reasons why CentOS is not suitable for tossing. Some software often uses low-level APIs or compiler versions.
CentOS 7.X is fine. GLIBC Version 2.17 and GCC Version 4.8.5 basically meet the requirements, but GLIBC Version 2.12 and GCC Version 4.4.7 of CentOS 6.X basically do not meet the requirements...
Look at someone else's copy. It's better than you don't know where to go.
Since CentOS 6.X has been used for a long time, it is quite troublesome to compile the source code directly when a problem occurs in the past. Now I plan to upgrade the RPM package directly, which is more convenient and less flexible than source code compilation. Here I will write down the specific methods and links for memo.
First, compare the advantages and disadvantages of three installation methods: Source code compilation, RPM package, and YUM:
Source code compilation: you can manually specify the compilation parameters. The degree of freedom is high, which is slightly troublesome. However, if the latest version is not installed, the BUGs and CVEs will not be repaired, and there is no difference with Xianyu;
RPM Package installation: the official version of the RPM package does not have a higher version, so you have to use a trusted third party to make the package. Sometimes the production time is a few years ago. It is similar to not using the latest version of the source code for compilation and will not be patched;
YUM installation: Although the versions in the YUM source are very low and don't change for years, but they are often updated and usually patched. The security is high, but the version is too low.
Upgrade GLIBC
First, determine which packages of GLIBC are installed in the current system and the maximum supported version.
[Root @ localhost src] # rpm-qa | grep glibc
Glibc-2.12-1.192.el6.x86_64
Glibc-devel-2.12-1.192.el6.x86_64
Glibc-headers-2.12-1.192.el6.x86_64
Glibc-common-2.12-1.192.el6.x86_64
[Root @ localhost src] # strings/lib64/libc. so.6 | grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE
It is found that glibc, glibc-common, glibc-devel and glibc-headers of x86_64 are installed in the system, and the version is 2.12-1.192.el6, during the upgrade, we need to download the above four RPM packages of the new version.
Note: glibc-related packages include glibc, glibc-common, glibc-devel, glibc-headers, glibc-static, and glibc-utils of x86_64 and i686. Please select them based on your actual situation.
Next, you can download the RPM Package of the corresponding version at ftp.redsleeve.org, rpmfind.net (x86_64), or Baike cloud. Note that the RPM package can only be used in the el6 release.
OK. After the file is finished, let us put the RPM package to be upgraded under the/usr/src directory.
Cd/usr/src
# Here, we only need to install four RPM packages.
Rpm-Uvh glibc-2.15-60.el6.x86_64.rpm \
Glibc-common-2.15-60.el6.x86_64.rpm \
Glibc-devel-2.15-60.el6.x86_64.rpm \
Glibc-headers-2.15-60.el6.x86_64.rpm
Although there seems to be a small error during the installation process, maybe does not matter?
After the installation is complete, check the installation status again.
[Root @ localhost src] # rpm-qa | grep glibc
Glibc-2.15-60.el6.x86_64
Glibc-devel-2.15-60.el6.x86_64
Glibc-headers-2.15-60.el6.x86_64
Glibc-common-2.15-60.el6.x86_64
[Root @ localhost src] # strings/lib64/libc. so.6 | grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_PRIVATE
Well, now there will be no more errors if the version is not enough. Of course, this is only Version 2.15.
Note: Once installed, YUM cannot be used for upgrade, and its various vulnerabilities will not be repaired.