一次失败的尝试,glibc2 14环境交叉编译glibc2 12程序

开发环境是ubuntu的,发现编译出的代码在centos6上不能运行,报version 'GLIBC_2.14' not found错误,原来是定位于稳定的centos glibc升级太慢了,ubuntu都飞到2.26了,这边才2.12。不过因为对glibc的依赖是根据程序中所用到特性的最高版本计算的,所以实际依赖是glibc2.14,相差不远。那么到底是什么特性用到了glibc2.14呢?

objdump -T app |grep GLIBC_2.14
复制代码

只有一个memcpy函数。google了半天,发现一个思路,能不能静态编译这个memcpy呢?

首先在搜索下载glibc的静态库,是一个rpm包,提取出需要的libc.a,然后从静态库中抽取二进制文件

rpm2cpio glibc-static-2.25.90-2.fc27.x86_64.rpm | cpio -div
ar x ./libc.a memcpy.o
复制代码

结果编译后发现什么也没变,还是老样子,怎么回事?用nm工具查看输出文件的符号

nm memcpy.o
复制代码

空的。。。那么memcpy跑哪里去了呢?

nm --defined-only libc.a |grep memcpy
复制代码

原来被移动到memmove.o了,猜想应该是做了某些优化,尽可能用move代替copy?

然后,编译不过。。附带上其他依赖?编译不过。。换用2.12以前的memcpy?编译不过。。放弃。。。还是老老实实在目标环境编译吧,glibc还是太底层,牵连太多。

虽然这次尝试以失败告终,但是也是把前几天看的链接器,静态库,动态库等相关内容都实践了一遍。

你可能感兴趣的:(一次失败的尝试,glibc2 14环境交叉编译glibc2 12程序)