Centos6.5 升级glibc解决“libc.so.6: version GLIBC_2.14 not found”“/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found“

写在前面：

研发发来邮件说线上有台服务器跑程序报错，信息如下：

./agent: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by./agent)

从上面报错可以看出，程序运行时候，没有找到“GLIBC_2.14”这个版本库，而默认的Centos6.5 glibc版本最高为2.12, 所以需要更新系统glibc库。

glibc是gnu发布的libc库，即c运行库，glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。

很多linux的基本命令，比如cp, rm, ll,ln等，都得依赖于它，如果操作错误或者升级失败会导致系统命令不能使用，严重的造成系统退出后无法重新进入，所以操作时候需要慎重。

解决办法：

查看系统版本和glibc库版本

# cat /etc/redhat-release 

CentOS release 6.5 (Final)

# 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

由上面的信息可以看出系统是CentOS 6.5，最高支持glibc的版本为2.12，而研发程序要2.14版本，所以需要升级。

下载软件并升级

# wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz 

# wget http://ftp.gnu.org/gnu/glibc/glibc-ports-2.14.tar.gz 

# tar -xvf  glibc-2.14.tar.gz 

# tar -xvf  glibc-ports-2.14.tar.gz

# mv glibc-ports-2.14 glibc-2.14/ports

# mkdir glibc-build-2.14

# cd glibc-build-2.14/ 

# ../glibc-2.14/configure  --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin

# make

注意：当make成功后，会在当前glibc-build-2.14目录下生成一个新的libc.so.6的软连接，指向的是本目录下的libc.so文件，如下所示：

# ll glibc-build-2.14/libc.so.6

glibc-build-2.14/libc.so.6 -> libc.so

可以将上面的libc.so文件直接拷贝到/lib64下面改名为libc-2.14.so，删除原来的libc.so.6软连接，建立新的连接即可使用，但是此处有一个大坑，后面会介绍，此处还是按照正常流程安装。

继续完成后续的安装： 

# make install

以上完成不报错的话，查看库文件，发现/lib64/libc.so.6软链接指向了2.14版本

# ll /lib64/libc.so.6 

/lib64/libc.so.6 -> /lib64/libc-2.14.so

再次查看glibc支持的版本

# 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_PRIVATE

可以看到版本已经glibc支持的版本已经到2.14，再次执行程序就不会报错了。

2、“/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found “ 报错解决

问题：到什么地方去找安装在本地的GLIBC库呢?又如何寻找对应版本呢？

答案：默认的动态链接库，存放的路径是/usr/lib64/libstdc++.so.6。但是，如果我们自己编译了GCC，对应的libc和libc++的库文件位置就会发生变化。假如我们的安装路径是?/usr/local/gcc4.8.3, 那么?对应的库文件位置是/usr/local/gcc4.8.3/lib:/usr/local/gcc4.8.3/lib64.

# strings libstdc++.so.6.0.19|grep GLIBCXX

一般来讲，里面就有满足需要的GLIBCXX版本了。

然后，把该文件拷贝到了/usr/lib64下.

方法一

然后将libstdc++.so.6指向libstdc++.so.6.0.19

方法二

上面的方法太过于暴力，可以使用以下方法：

There is 1 program that provides 'libstdc++.so.6'.

  Selection Command

-----------------------------------------------

*+ 1 /opt/anaconda3/lib/libstdc++.so.6.0.19

Enter to keep the current selection[+], or type selection number: 1

其他知识点

1、有些安装方法是编译时候指定的目录不是/usr,而是通过建立软链指向新的libc-2.14.so版本,在此过程中需要删除原来连接，建立新的软连接，但是此处有一个大坑，就是当你删除libc.so.6之后会导致系统命令不可用,如下在测试机中演示的错误过程：

# rm -rf /lib64/libc.so.6

接下来当你建立新的软链接时候，会发现ln命令不能用了。

# ln -s /lib64/libc-2.14.so /lib64/libc.so.6

ln: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

方法一：

当出现上面的状况时候，可以使用以下方法解决:

# LD_PRELOAD=/opt/glibc-2.14/lib/libc-2.14.so ln -s /opt/glibc-2.14/lib/libc-2.14.so /lib64/libc.so.6

当然如果升级失败，还可以使用下面命令还原至系统升级前的版本libc-2.12.so: 

# LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6

“LD_PRELOAD”是一个环境变量，定义在程序运行前优先加载的动态链接库，本处作用就是在执行后面的ln命令时，指定使用的glibc库，这样命令就可以正常使用了。

方法二：

有时候上面得命令也无法修复，可以使用sln 这个命令修复，这个命令不会调用libc动态库

# sln  /lib64/libc-2.14.so /lib64/libc.so.6