Linux下GLIBCXX和GLIBC版本低造成的编译错误的解决方案

最近在给编译环境centOS 6.5安装新版clang (clang 3.4/3.5)的时候,虽然已经装了gcc 4.9.1, 但编译的时候(参考clang官方主页http://clang.llvm.org/get_started.html的步骤,在独立build目录下运行clang自带的configure脚本),仍然出了“c compiler
cannot create executables”的提示,去查看log信息,发现里面有下面几个错误:

clang: /lib64/libc.so.6: version `GLIBC_2.15‘ not found (required by clang)
clang: /lib64/libc.so.6: version `GLIBC_2.14‘ not found (required by clang)
clang: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18‘ not found (required by clang)
clang: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15‘ not found (required by clang)

这里是两个系统版本库版本过低的问题,一个是关于C++的库libstdc++, 一个是关于C系统基础运行库GLIBC,前者比较好办,后者十分基础,一般一个版本的centos会指定一个GLIBC,可以去升级,但这样CentOS本身版本的稳定性的可能就会被破坏。

1. 我们着手解决GLIBCXX的问题,C++库,首先查看错误信息提示中的lib文件的信息。

$ strings /usr/lib64/libstdc++.so.6 | grep GLIBC
  • 这里是打印 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.3  
GLIBC_2.2.5  
GLIBC_2.3.2  
GLIBCXX_FORCE_NEW  
GLIBCXX_DEBUG_MESSAGE_LENGTH

    $ll  /usr/lib64/libstdc++.so.6  
     
    lrwxrwxrwx 1 root root 30 Sep 23 06:21 /usr/lib64/libstdc++.so.6 -> /usr/lib64/libstdc++.so.6.0.13

      也就是系统以前有一个6.0.13版本,确实比较旧了,那么我们有新版本么?我们安装了gcc 4.9.1,按理说应该已经装了新版的libstdC++.,如果没有,可以去网上下一个。

      先在本机找:

      find / -name libstdc++.so.6*
      • 我们发现,gcc安装时把/libstdc++.so.6.0.20 安装到了/usr/local/lib64下,但并没有改变libstdc++.so.6的链接指向。

      那么我们手动来更新软连接(也可以字节指向/usr/local下的文件,不用拷贝, 看鸽子的文件管理习惯)

       
      $ cp /usr/local/lib64/libstdc++.so.6.0.20 /usr/lib64   
      $ rm -rf /usr/lib64/libstdc++.so.6  
      $ ln -s /usr/lib64/libstdc++.so.6.0.20 /usr/lib64/libstdc++.so.6  
      $ 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  
        GLIBC_2.3  
        GLIBC_2.2.5  
        GLIBC_2.3.2  
        GLIBCXX_FORCE_NEW  
        GLIBCXX_DEBUG_MESSAGE_LENGTH

          库更新完毕。我们已经支持到了GLIBCXX_3.4.20

          此时再进行编译,GLIBCXX的问题是没有了。

          2. 关于C基本运行库GLIBC,因为要慎重,所以我写在下一篇博客:

          《Linux/CentOS 升级C基本运行库CLIBC的注意事项(当想解决GLIBC_2.x找不到的编译问题)》

          时间: 2024-10-10 15:50:13

          Linux下GLIBCXX和GLIBC版本低造成的编译错误的解决方案的相关文章

          linux下apache+mysql+php开发环境纯源代码编译搭建

          linux下apache+mysql+php开发环境纯源代码编译搭建 记录一下我在fedora core 1下通过源代码编译出来的apache+mysql+php开发环境的全部过程 通常安装一台服务器当然使用rpm是最方便的,不需要考虑太多配置的问题,就可以轻松获得需要的环境了.不过rpm包互相关联的问题也不是这么容易解决. apache,mysql,php这三个应用从源代码编译安装还是比较简单的,配置参数不算复杂,而且没有太多的依赖关系,从源码编译出来的系统也比较稳定一些,方便未来打补丁和升级

          Linux下使用vi新建文件保存文件时遇到错误:E212: Can't open file for writing

          出现E212: Can't open file for writing的问题是由于权限问题导致的,解决方法有以下思路: 1.使用root进行登录,然后再操作. 2.在使用命令时,前面加sudo. 3.如果是多级文件夹的文件时,由于这个文件夹没有创建,所以要先创建这个文件夹,再来操作这个文件. Linux下使用vi新建文件保存文件时遇到错误:E212: Can't open file for writing

          Linux下不能进入windows的NTFS分区之挂载错误问题(error mounting)

          问题描述 装了Windows 8.1与Ubuntu双系统后,在Ubuntu系统下想进入Windows的某个NTFS分区,点击时却出现下面错误: Error mounting /dev/sda2 at /media/love/Mis Archiivos: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" &quo

          linux下安装codeblocks及写完程序之后编译成功但无法运行的原因

          一:在软件中心输入codeblocks,然后点击安装,等着装完就行了. 再按ctrl+alt+t 打开终端 输入 sudo apt-get install gcc 而后再输入sudo apt-get install g++ 最后打开codeblocks写个 helloworld 试试吧. 二:helloworld小程序写完后,也编译通过了,但是却无法运行,那么你再看看保存的地方吧,要是不是保存在linux下的文档了,而是保存在磁盘里的话就是造成不能运行的结果了,更改保存位置试试看呗. 以上仅是我

          Windows/Linux下引用jar包,并用javac/java编译运行

          Windows/Linux下引用jar包,并用javac/java编译运行,有需要的朋友可以参考下. 1> Windows 假设要引用的jar放在D:/test目录下,名字为t1.jar, java源文件放在D:/test/src目录下,名字为t2.java. 编译: javac -cp d:/test/t1.jar d:/test/src/t2.java 运行: java -cp d:/test/t1.jar;d:/test/src t2 注意,分号后面没有空格,否则报错. 需要注意的是,如果

          linux下FTP的工具和使用以及rpmReadSignature failed错误

          安装rpm文件时提示rpmReadSignature failed 错误 2011-09-23 11:04 现象: [[email protected] share]# rpm -ivh syslog-ng-3.1.0-1.rhel5.i386.rpm error: syslog-ng-3.1.0-1.rhel5.i386.rpm: rpmReadSignature failed: region trailer: BAD, tag 15872 type 2047 offset 28672 cou

          Linux下网卡驱动和版本信息

          查看网卡生产厂商和信号 查看基本信息:lspci 查看详细信息:lspci -vvv   # 3个小写的v 查看网卡信息:lspci | grep Ethernet 查看网卡驱动 查看网卡驱动信息:lspci -vvv # 找到网卡设备的详细信息,包括网卡驱动 # lsmod    列出加载的所有驱动,包括网卡驱动 查看网卡驱动版本 查看模块信息:modifo<module name>   # 其中包含version信息 或 # ethtool-i <device name> RH

          Linux下同时运行不同版本的qt程序

          因项目需要,可能有不同版本的qt程序要运行到同一台机器上,本次实验是qt4.8.5和qt5.3.1开发的程序同时运行在同一台机器上,此机器可以不按照qt的任何版本,当然,两个版本开发的qt与机器的位数必须一样,例如都是32位或者64位. 两个版本的qt的程序我都采用动态编译(静态编译方法请度娘),所以需要把运行程序所需的动态库放到程序可以链接的地方,程序可以链接的动态库路径参见:linux动态库搜索路径.此处直接贴出结论:动态库的搜索路径搜索的先后顺序是: 1.编译目标代码时指定的动态库搜索路径

          linux下依赖库的版本问题引起的安装失败:libssl-dev版本问题无法安装 :libssl-dev : 依赖: libssl1.0.0 (= 1.0.1-4ubuntu3) 但是 1.0.1-4ubuntu5.31 正要被安装

          依赖库版本问题引起的安装失败解决方法如下有两种: 1.是由于源需要更新,如下操作: libssl-dev : 依赖: libssl0.9.8 (= 0.9.8o-1ubuntu4) 但是 0.9.8o-1ubuntu4.4 正要被安装 解决方法 进入“系统->系统管理->更新管理器->设置”,在弹出的“软件源”对话框中选“更新”标签页,选中“Ubuntu 更新”下面的四个复选框,关闭后 在终端先执行“sudo apt-get update”就ok了. 转自:http://baalwolf