在实际的生产环境中，系统基础库的升级从来都不是一件可以草率决定的事情——尤其是像 glibc 这种核心库，一旦操作不当，整个系统的命令链都可能崩溃。然而，项目需求有时迫使我们必须向前迈出一步。例如，CentOS 6.5 默认搭载的 glibc 最高版本仅为 2.12，而 Node.js 开发过程中许多依赖包却要求更高版本的 glibc 支持。如果不想对整个系统进行全局升级（毕竟牵一发而动全身），那么手动升级 glibc 就成了一个绕不开的解决方案。

当你遇到类似 libc.so.6: version GLIBC_2.14 not found 这样的错误提示时，说明时机已经成熟——是时候给 glibc 动一个“小手术”了。

glibc 版本查询

首先，确认当前系统中 glibc 的具体版本号，做到心中有数。使用下面这条命令可以快速查看：

$ strings /lib64/libc.so.6 |grep GLIBC_

在 CentOS 6.5 上执行后，会输出类似下图所示的 glibc 版本列表。从输出结果可以看出，系统最高只支持到 2.12 版本：

此外，执行 $ ll /lib64/libc** 可以看到当前的 libc.so.6 实际上是一个软链接，指向的是 libc-2.12.so，如下图所示：

glibc 安装步骤

确认现状后，就可以开始动手升级了。首先需要获取 glibc-2.14 的源码包。下载完成后，进行解压：

$ tar -xzvf glibc-2.14.tar.gz

解压后会得到一个 glibc-2.14 目录。进入该目录，然后按照标准的编译流程操作：

$ cd glibc-2.14
$ mkdir build          // 在 glibc-2.14 目录下创建 build 文件夹
$ cd build
$ ../configure --prefix=/opt/glibc-2.14   // 配置安装路径，这里选择 /opt/glibc-2.14
$ make && make install  // 编译并安装

整个编译安装过程可能需要几分钟，请耐心等待其完成。

glibc 软链接更新

安装完成后，需要将系统的 libc.so.6 软链接指向新版本的库。先删除旧软链接，再建立新链接：

$ rm -rf /lib64/libc.so.6          // 删除旧的软链接
$ ln -s /opt/glibc-2.14/lib/libc-2.14.so /lib64/libc.so.6

注意事项

这一步有一个比较棘手的地方：一旦删除了 libc.so.6，许多系统命令会立即失效——因为几乎所有动态链接的程序都依赖它。如果不小心操作失误，不要慌张，可以借助 LD_PRELOAD 环境变量来进行“抢救”：

$ 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

如果连上面这条命令都无法执行，或者希望回退到旧版本，可以用类似的方式将软链接指向原来的库文件：

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

（请注意，libc-2.12.so 需要替换为你系统升级前的实际版本号。）

完成软链接更新后，再次使用 strings /lib64/libc.so.6 |grep GLIBC_ 检查，就能看到最高版本已经变为 2.14 了：

同时，libc.so.6 的指向也发生了变化，现在它指向的是 libc-2.14.so：

到这里，glibc 升级操作就完成了。需要提醒的是，这种手动升级方式仅适用于对风险有充分预估的场景——毕竟 rm -rf /lib64/libc.so.6 这条命令，在输入之前最好深呼吸三次。