一次失败的尝试，glic2.14环境交叉编译glic2.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还是太底层，牵连太多。

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