求助：CentOS 7.2安装gcc 5.3后出现GLIBC系列版本错误

作为经常处理CentOS系统编译问题的开发者，我来帮你梳理下这两个错误的根源和解决办法：

问题根源分析 #

1. GLIBCXX_3.4.20 not found：CentOS 7默认自带的gcc是4.8.5，对应的libstdc++.so.6只包含到GLIBCXX_3.4.19，所以当你运行依赖更高版本C++标准库的程序时会报错。
2. GLIBC_PRIVATE not defined：你跟着教程直接安装gcc 5.3后，很可能不小心替换了系统默认的libstdc++或者破坏了glibc相关的链接（比如ld-linux-x86-64.so.2），导致系统库版本冲突——GLIBC_PRIVATE是glibc的内部符号，不同版本的glibc和gcc库混用就会触发这个错误。

正确的解决方案（安全不破坏系统） #

1. 通过SCL安装隔离版的gcc 5.3

CentOS官方提供了Software Collections（SCL）源，用来安装高版本的开发工具，同时不会替换系统默认的库，完美解决冲突问题：

• 先安装SCL源：

  sudo yum install centos-release-scl
  

• 安装gcc 5.3对应的工具集（devtoolset-4对应gcc 5.3）：

  sudo yum install devtoolset-4-gcc devtoolset-4-gcc-c++
  

• 激活该环境（当前shell生效）：

  scl enable devtoolset-4 bash
  

  现在你可以用gcc --version验证，已经切换到5.3版本了，同时系统默认的4.8.5不受影响。

2. 修复GLIBC_PRIVATE错误

如果之前的操作已经破坏了系统库，先恢复默认的glibc和ld链接：

• 检查ld-linux-x86-64.so.2的指向，正常应该是ld-2.17.so（CentOS7默认glibc版本）：

  ls -l /usr/lib64/ld-linux-x86-64.so.2
  

• 如果指向异常，重新安装glibc恢复：

  sudo yum reinstall glibc
  

• 之后再用SCL的方式激活gcc 5.3环境编译运行程序，就不会再出现符号错误了。

3. 永久使用gcc 5.3（可选）

如果想每次登录都自动激活该环境，把激活命令加到你的~/.bashrc：

echo "source scl_source enable devtoolset-4" >> ~/.bashrc

执行source ~/.bashrc或者重新登录后，环境就永久生效了。

新手提醒 #

不要尝试直接替换系统默认的gcc或者libstdc++.so.6，CentOS 7的很多系统工具依赖默认的4.8.5版本，强行替换会导致系统不稳定甚至崩溃。SCL隔离环境是官方推荐的安全方案。

内容的提问来源于stack exchange，提问作者vicky