在系统CentOS release 6.4 (Final) x86_64上操作
1.试图运行程序
提示”libc.so.6: version `GLIBC_2.14′ not found”,原因是系统的glibc版本太低,软件编译时使用了较高版本的glibc引起的.
2.查看系统glibc支持的版本
strings /lib64/libc.so.6 |grep GLIBC_
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
rpm -qa |grep glibc
1 2 3 4 5 6 7 8 |
|
3.可以看到最高只支持2.12版本,所以考虑编译解决这个问题
1). 到官网 http://www.gnu.org/software/libc/ 或FTP http://ftp.gnu.org/gnu/glibc/ (推荐)下载最新版本,这里下载了glibc-2.14.tar.xz 版本,解压到任意目录准备编译
2).这里解压到 /opt/glibc-2.14
3).新建目录 /opt/glibc-2.14-install ,并cd进入此目录:
mkdir /opt/glibc-2.14-install
cd /opt/glibc-2.14-install
4). 新建安装目录 /opt/glibc-2.14-build
mkdir /opt/glibc-2.14-build
并运行configure配置,make && sudo make install
在 cd /opt/glibc-2.14-install 目录下,执行
/opt/glibc-2.14/configure �Cprefix=/opt/glibc-2.14-build/
make -j4
make install
4. 临时修改环境变量
export LD_LIBRARY_PATH=/opt/glibc-2.14-build/lib:$LD_LIBRARY_PATH
注意: glibc-2.14-build 是安装目录
―――――――�C
version `GLIBC_2.14′ not found 解决方法
一般出现类似次问题是当前运行系统Glibc版本低于编译环境Glibc版本造成Glibc版本兼容性造成的.
通常可以使用-static链接成静态程序即可解决.
不过经过google大神发现还有另外一种方法可以在使用动态库的环境下规避此类问题.
首先查看APP Glibc 兼容性.看当前app使用了哪些Glibc版本.
objdump -p libalgrms.so
1 2 3 4 5 6 7 8 9 10 11 |
|
然后查看当前app引用了GLIBC_2.14中哪些函数
nm libalgrms.so | grep GLIBC_2.14
1 2 |
|
也可以使用 objdump 查看app动态引用符号表.
objdump -T libalgrms.so | grep GLIBC_2.14
[root@localhost lib]# objdump -T libalgrms.so | grep GLIBC_2.14
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy
上例显示app引用 2.14 版本中的memcpy函数.
下面将用到 gcc 的一个特性实际上是ld的特性.可以将引用符号绑定到一个特定版本.只需在.c文件中写入类似代码.
__asm__(“.symver original_foo,foo@VERS_1.1″);
即可.
查找当前系统glibc版本中memcpy的各个版本.
获取libc.so实际路径.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
获取memcpy版本信息.
1 2 3 4 5 |
|
可以看出memcpy最低版本是(“@GLIBC_2.2.5″)2.2.5,而默认使用版本是2.14(“@@GLIBC_2.14″) 这里我们只要将 glibc 2.14 版本memcpy降到glibc 2.2.5. 在源代码写入以下代码
__asm__(“.symver memcpy,memcpy@GLIBC_2.2.5″);
重新编译.
再次查看app信息.
1 2 3 4 5 6 7 8 9 |
|
发现当前版本需求已不再需要glibc 2.14支持.
1 2 |
|
memcpy已完全修改为Glibc 2.2.5支持.
至此完美解决. 再次运行一切完美