Linux升级gcc

在运行一些编译后的C类二进制程序时,会遇到报错如下:
 
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21‘ not found
 
这里你就要知道,是你的gcc版本低了,同时你可以检测一下本机所支持的glibc版本范围
 
[ ~]# 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
 
这里的/usr/lib64/libstdc++.so.6 要用绝对路径,如果找不到就 find。你会发现,报错里面包含的版本确实没有,此时就要考虑升级gcc了~
 
gcc各版本的下载地址:
 
 
目前5.1.0版本的能提供到 GLIBCXX_3.4.21
 
我们一般下载tar.gz包,下载之后就进行我们的编译过程(以5.1.0为例):
 
1:tar -zxvf gcc-5.1.0.tar.gz
2:cd gcc-5.1.0
3:./contrib/download_prerequisites
4:cd ../
5:mkdir gcc-build-5.1.0
6:cd gcc-build-5.1.0/
7:../gcc-5.1.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
8:make -j8
9:make install
 
 
这个过程,网上说要三个小时左右,但我这里似乎只跑了一个小时~
 
跑完之后还要进行一些操作,替换原来的软连接到新版本的gcc库上:
 
1:find / -name  libstdc++.so.6*
此时你看到系统下面全部的libstdc++.so.6*,把这个库全部删掉,重新做软连接:
新的库就在刚刚新编译的目录下:
/root/gcc-build-5.1.0/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21
/root/gcc-build-5.1.0/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
/root/gcc-build-5.1.0/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21
/root/gcc-build-5.1.0/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
/root/gcc-build-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21
/root/gcc-build-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
把libstdc++.so.6.0.21复制到find出来的目录里,删除原来软连接,重新软连接到libstdc++.so.6.0.21上!
 
cd gcc-build-5.1.0/
find . -name libstdc++.so.6
ll /usr/lib64/libstdc++.so.6
cp ./prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21 /usr/lib64/
rm -rf /usr/lib64/libstdc++.so.6
ln -s libstdc++.so.6.0.21 libstdc++.so.6
ll libstdc++.so.6
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3
 
这里共享库升级好了之后,可以先测试下gcc的版本:
gcc -v
如果还是之前的老版本的话,那么就是二进制文件的更新问题了:
 
[ gcc-build-5.1.0]# find / -type f -name gcc
/usr/local/bin/gcc
/usr/bin/gcc
这里,/usr/local下的是新安装的gcc命令,此时把原来的/usr/bin/gcc bak掉
cp /usr/local/bin/gcc /usr/bin/gcc
此时再次执行:
[ gcc-build-5.1.0]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)
 
ok,升级到5.1了!
这里需要注意的是,如果有编译需求的话,是走g++的,这里看下:
[ ~]# g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
 
很奇怪,g++还是老版本,操作步骤同上,再执行一遍g++
gcc的编译包中也会包含g++的二进制,find一下就即可:
[ ~]# find / -name g++
/usr/local/bin/g++
/usr/bin/g++
[ ~]# mv /usr/bin/g++ /usr/bin/g++_bak
[ ~]# cp /usr/local/bin/g++ /usr/bin/g++
[ ~]# g++ -v                            
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)
 
OK,这里就正常升级了!
 
[_13_117_centos ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)
 
你会发现已经变成5.1了,同时,再执行之前的strings指令:
 
[_13_117_centos ~]# 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.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBC_2.3
GLIBC_2.2.5
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
 
现在最高就到GLIBCXX_3.4.21,同时原先的程序就也能开起来了!

注意:这里需要注意,开发环境和线上环境的完全一致性,尤其是c类的程序编译过程中的参数选择问题,使用满足陈旭运行的共享库版本即可,而不是一味追求高版本,笔者上面的问题就是因为开发擅自修改了编译参数,导致编译后的二进制在6系和7系自带的gcc环境下没法运行,必须升级,而升级gcc又是比较麻烦的事情,后面找到问题,改回参数,就不存在上面报错的问题了!

以上,共勉!

相关推荐