旧版glibc兼容旅程
一.背景
在新环境编译程序部署到老环境运行。
为什么不直接在老环境里面编译？因为用到了一点c++11的特性，需要较高版本的gcc进行编译；老环境默认的gcc版本太低，新版gcc的rpm包安装部署不上（glibc版本太低），源码安装高版本gcc又太麻烦。
二. 错误表现
注: server名字做过修改, 暂且叫my_server.
运行时报错，找不到GLIBC_2.14的符号:
而本机glibc的版本才2.12:
glibc官方最新版本虽然为glibc_2.23. 但是编译机gblic版本为glibc_2.17.
所以只需要查看my_server用到了哪些>2.12, <=2.17的glibc符号即可:
如图所示, 只有一个memcpy超过了本机glibc的版本.
三. 问题解决
现在得想办法去除对高版本(2.14)memcpy的引用, 改为引用对应的低版本.
3.1静态链接
最简单的办法无非是静态链接了,但是在链接时jemalloc跟libc有重复的符号定义:
去除对jemalloc的依赖, 编译通过, 但是有一堆告警, 部分告警如下:
考虑到多线程环境下, 最好使用jemalloc(或者tcmalloc)来管理内存分配和释放. 所以不能去除对它的依赖, 也就不能用静态链接.
3.2符号版本指定
3.2.1编译时符号指定
如果用动态链接的话, 就要想办法在编译的时候强制引用2.12(运行环境的glibc版本)以下版本的memcpy.
先看看运行环境下的memcpy的版本:
nm没有看到版本信息.
试试objdump:
显示当前环境的memcpy版本是GLIBC_2.2.5.
接下来就是想办法在动态链接的时候强制引用memcpy的2.2.5版.
用汇编指令.symver可以完成版本指定(确保在所有调用 memcpy之前完成汇编指令的版本指定):
但是编译之后发现依旧引用了2.14版的memcpy
一开始以为是汇编指令不管用, 后来发现链接的若干公共库(.a)也有对memcpy的引用,因为公共库在编译的时候已经指定了对memcpy的2.14版, 所以这里的汇编指令对其是没有效果的.看来还是要在链接的时候做一些手脚.
3.2.2链接时符号指定
编译时指定符号版本对编译好的公共库不管用, 可以在链接的时候对引用的符号进行接管.
答案是使用ld的wrap功能, 选项说明如下:
a) 首先创建一个wrap函数
因为是在cpp代码中引用, 所以这里需要加extern “C”, 否则链接的时候会报错:
undefinedreference to __wrap_memcpy
b) 然后编译的时候注意加上-Wl,--wrap=memcpy(或者-Xlinker --wrap=memcpy)选项, 将—wrap选项传递给链接器. 编译完成后检查memcpy的符号:
很好,现在没有对memcpy的高本版的引用了. 放到运行环境运行看看:
对GLIBC的引用正常了, 现在又出现对GLIBCXX的引用问题.
my_server引用了3个GLIBCXX_3.4.14版的符号:
而运行环境最高只支持GLIBCXX_3.4.13:
c) 对GLIBC静态链接不满足需求, 但是单独将c++库进行静态链接是没有问题的, 于是编译时加上-static-libstdc++选项.
但是链接找不到stdc++库:
原来是因为编译环境只有c++的so库, 没有对应的静态库:
最后从一台云主机(gcc 4.8.4)下载了一个libcstdc++.a到开发机(gcc4.8.2),然后再编译链接,一切变得正常了.
四. 总结
１. 整体静态链接可以解决符号问题，但是会导致不能使用jemalloc(或者tcmalloc)
２. 用汇编指令.symver可以指定当前编译的memcpy版本, 却无法指定已经编译好的库中使用的memcpy的版本
３. 定义一个包装函数__wrap_memcpy, 在链接阶段(需要指定相应的—wrap选项)接管所有对memcpy的引用.
４. 单独将c++库进行静态链接.