注：以下所有操作均在CentOS 6.8 x86_64位系统下完成。
CentOS上yum安装的gcc版本过低（4.4.7），在安装某些软件的时候不支持，所以这里需要对其进行升级。
#gcc的安装#
开始下载gcc并进行编译安装：
# cd /usr/local/src # wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.9.4/gcc-4.9.4.tar.gz # tar zxf gcc-4.9.4.tar.gz # cd gcc-4.9.4 # ./configure --prefix=/usr/local/gcc-4.9.4 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++ ... configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify ...
直接进行configure的时候出错了！提示缺少GMP、MPFR和MPC。但是如果单独去下载这三个包并单独编译比较麻烦，这里有个推荐的方法是执行download_prerequisites文件。我们来查看该文件：
# vim contrib/download_prerequisites ... # Necessary to build GCC. MPFR=mpfr-2.4.2 GMP=gmp-4.3.2 MPC=mpc-0.8.1 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1 ...
可以看到该文件会自动去下载关联的软件包，并且放置到当前目录下，跟gcc一起编译，这样更加方便。
# contrib/download_prerequisites # ./configure --prefix=/usr/local/gcc-4.9.4 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++
... configure: creating ./config.status config.status: creating Makefile
这次通过了！
在configure的时候我们加入了一些参数，这些参数主要表示的是：
- --prefix：指定安装路径。
- --enable-threads=posix：启用POSIX标准的线程支持。要让程序能在符合POSIX规范的linux发布版上正确运行，就应该启用该选项。这里取决于目标操作系统的类型，其它可用值有：aix、dec、solaris、win32等。
- --disable-checking：不对编译时生成的代码进行一致性检查（检查的话一般设置为：--enable-checking=release）。建议机器硬件配置较低以及不愿等待太久编译时间的童鞋，可以设置为disable，但是这会增加产生未预期的错误的风险。
- --disable-multilib：如果你的操作系统是32位，默认就已经设置为disable，这意味着gcc仅能生成32位的可执行程序。如果你的操作系统是64位，默认设置为enable，这意味着用gcc编译其它源文件时可以通过-m32选项来决定是否生成32位机器代码。由于我们这里是64位系统上，所以要禁止生成32位代码。
- --enable-languages=c,c++：支持的高级语言类型和运行时库，可以设置的所有语言还包括ada、Fortran、java、objc、obj-c++、GO等语言。这里只开启了c和c++，因为支持的语言越多，就需要安装越多的相应静态与动态库，等待的时间也越久。
接下来就是编译安装，这个时间会比较久，这里差不多等了两个多小时。
# make # make install
#更新环境#
这个时候使用gcc命令时默认调用的还是旧的/usr/bin/gcc，所以需要更新环境变量：
# gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) # vim /etc/profile export PATH=/usr/local/gcc-4.9.4/bin:$PATH # source /etc/profile # gcc --version gcc (GCC) 4.9.4
#更新动态库#
虽然现在gcc命令已经升级了，但是在编译或运行某些程序的时候，有可能会出现类似：
| /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found |
的错误，这是因为升级gcc时，生成的动态库没有替换老版本gcc的动态库所导致的，所以这个时候还需要将gcc最新版本的动态库替换系统中老版本的动态库。
# strings /usr/lib64/libstdc++.so.6 | grep GLIBC GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBC_2.2.5 GLIBC_2.3 GLIBC_2.4 GLIBC_2.3.2 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH
可以看到上面的动态库还是旧版本的动态库，没有更新。
# find / -name "libstdc++.so*" /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libstdc++.so /usr/lib64/libstdc++.so.6.0.13 /usr/lib64/libstdc++.so.6 /usr/local/gcc-4.9.4/lib64/libstdc++.so.6.0.20-gdb.py /usr/local/gcc-4.9.4/lib64/libstdc++.so /usr/local/gcc-4.9.4/lib64/libstdc++.so.6.0.20 /usr/local/gcc-4.9.4/lib64/libstdc++.so.6 ...
可以看到旧的动态库是6.0.13，新的动态库是6.0.20。而.so.6是做了个软链：
# ls -l /usr/lib64/libstdc++.so.6* lrwxrwxrwx 1 root root 19 Apr 10 17:39 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.13 -rwxr-xr-x 1 root root 987096 Mar 14 02:49 /usr/lib64/libstdc++.so.6.0.13
所以这里我们可以将新的库复制到/usr/lib64/目录并且重新做个软链：
# cp /usr/local/gcc-4.9.4/lib64/libstdc++.so.6.0.20 /usr/lib64/ # cd /usr/lib64/ # rm -f libstdc++.so.6 # ln -s libstdc++.so.6.0.20 libstdc++.so.6 # ls -l libstdc++.so.6* lrwxrwxrwx 1 root root 19 Apr 14 15:24 libstdc++.so.6 -> libstdc++.so.6.0.20 -rwxr-xr-x 1 root root 987096 Mar 14 02:49 libstdc++.so.6.0.13 -rwxr-xr-x 1 root root 6779620 Apr 14 15:23 libstdc++.so.6.0.20
这个时候我们可以重新来查看下是否已经包含了最新库：
# strings /usr/lib64/libstdc++.so.6 | grep GLIBC GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBC_2.3 GLIBC_2.2.5 GLIBC_2.3.2 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH
可以看到动态库已经成功更新。