1:问题背景描述

在拥有高版本glibc的机器上编译分布式xgboost程序,结果在拥有低版本glibc版本的集群机器上无法运行,总是报错,显示缺少glibc_2.14,为了解决整个问题,google查阅了很多资料,大体给出了两种方案:

方案一:升级集群所有机器的glibc版本以满足程序运行要求,但是升级glibc是有很大风险的,尤其是在生产环境,风险最大,所以放弃这个方法!

方案二:在低版本的glibc版本的机器上重新编译我们的分布式xgboost,由于报错需要高版本的glibc的文件只有少数,所以重新编译整个xgboost不划算,比较麻烦,而且还有一种情况,这种办法是无法解决的,那就是某个程序引用了高版本glibc才有的某个接口或函数,这个时候用低版本的glibc编译显然不能提供这个函数,故这种方法也不可取。

2:解决办法

后来偶然在谷歌上看到了一片文章,链接为:

https://zohead.com/archives/mod-elf-glibc/

按照文章中的方法,首先需要查看我们的xgboost是哪个文件引用了高版本的glibc,在运行xgboost之后,从运行日志中看到下面内容:

可以看到该xgboost文件引用了高版本的glibc_2.14,我们接着可以检查一下该程序使用了新版本 glibc_2.14 的哪些符号,使用 objdump 命令可以查看 ELF 文件的动态符号信息,使用命令objdump –T xgboost |grep “GLIBC_2.14”,显示内容如下:

可以看到,该xgboost文件只引用了glibc_2.14中的memcpy符号。

接下来我们需要查看我们系统【也就是集群中拥有较低版本glibc的那些机器】含有的glibc中是否含有这个memcpy符号,如果有,那就最好,如果没有,那就麻烦了。切换到/lib64下,使用命令:objdump -T libc.so.6 |grep "memcpy",可以看到,低版本的glibc也提供了memcpy符号。

那么现在整理一下头绪,目前到此为止,我们找到了分布式xgboost不能在所有集群机器上运行的原因,原因是我们编译的分布式xgboost中的xgboost文件【注意,这只是一个文件,和我说的分布式xgboost不要搞混了,分布式xgboost是一个大工程,而现在说的只是这个大工程中的一个文件而已】,这个文件引用了高版本的glibc_2.14中的memcpy函数,而刚好,我们发现低版本的glibc_2.2.5中也有这个函数,所以现在最直接的方法就是通过修改该xgboost文件的ELF内容,强制它去调用glibc_2.2.5中的memcpy函数,而不是去调用glibc_2.14中的memcpy,不然它找不到就会报错。

 

接下来我们修改xgboost文件的ELF内容,【注意,这次修改是修改16进制数字,所以为了保险起见,先备份xgboost文件】,通过我上面那个博客里面的讲解,我们需要查看该xgboost文件。

 

虽然我们无法重新编译第三方程序,但如果可以修改 ELF 文件强制让 LD 库加载程序时使用老版本的 memcpy,应该就可以避免升级 glibc

分析 ELF

首先用 readelf 命令查看 ELF 的符号表,由于该命令输出非常多,这里只贴出我们关心的信息:

使用命令:readelf -sV xgboost

显示内容如下:

在表中,可以看到Glibc_2.14Glibc_2.2.5以及它后面的数字19和3,也就是他们两个的十进制的版本号。其次我们可以看到.gnu.veersion_r文件的起始偏移量是0x003d00.

.gnu.version_r 表示二进制程序实际依赖的库文件版本,从输出中也能看到 .gnu.version_r 表是按照不同的库文件进行分段显示的,每个条目占用 0x10 也就是 16 个字节,该表是从 0x003d00偏移量开始,我们打开xgboost文件找到该起始位置:使用vim xgboost命令内容如下:

看不懂,我们切换到16进制查看,使用命令:%!xxd打开文件,找到起始位置,内容如下:

红线标注位置即为.gnu.version_r 的起始位置,下面我们需要根据偏移量找到glibc_2.14和glibc_2.2.5的位置,修改内容,这里起始位置为0x003d00,十进制是15616,而通过readelf –sV xgboost命令查看到的glibc_2.14偏移量是:0x00c0十进制是192,glibc_2.2.5偏移量是0x00d0,十进制是208,现在我们给.gnu.version_r 的初始位置加上偏移量,分别得到glibc_2.14的位置是15616+192=15808,转换成16进制是0x003dc0,glibc_2.2.5加上偏移量之后的位置是15616+208=15824,转换为16进制就是0x003dd0,现在我们找到这两个位置,如下:

可以看到,有红线的上面那行是3dc0也就是glibc_2.14, 下面3dd0是glibc_2.2.5,

那么现在该怎么改,改什么?

修改 ELF 符号表

由于 Linux 系统中的 LD 库(也就是 /lib64/ld-linux-x86-64.so.2 库)加载 ELF 时检查 .gnu.version_r 表中的符号,我们可以来修改 .gnu.version_r 表中的符号值来强制使用老版本的函数实现。

 

.gnu.version_r 表中每个条目是 16 个字节的 Elfxx_Vernaux 结构体,其声明如下(Elfxx_Half 占用 2 个字节,Elfxx_Word 占用 4 个字节):

 

typedef struct {

    Elfxx_Word    vna_hash;   //占4字节

    Elfxx_Half    vna_flags;  //占2字节

    Elfxx_Half    vna_other;  //占2字节

    Elfxx_Word    vna_name;   //占4字节

    Elfxx_Word    vna_next;   //占4字节

} Elfxx_Vernaux;

vna_hash 为 4 个字节的库名称(也就是上面的 GLIBC_2.14 字符串)的 hash 值,vna_other 为对应的 .gnu.version 表中符号的版本值,vna_name 指向库名称字符串的偏移量(也可以在 ELF 头中找到),vna_next 为下一个条目的位置(一般固定为 0x00000010)。

因此我们需要修改glibc那行内容的vna_hash, vna_other, vna_name 这三部分内同容和glibc_2.2.5相同即可。也就是前四个字节内容,7~8字节内容和9~12字节内容。

使用命令vim xgboost打开xgboost文件,再使用命令:%!xxd切换到16进制显示,找到0x003dc0,显示如下:

 

现在我们下面那行标红线的内容复制到上面同等位置,复制完后的内容如下:

再使用:%!xxd –r命令退出16进制显示,再使用:wq保存文件退出,修改保存之后的 ELF 文件再使用 readelf 命令检查就能看到变化了(只列出了修改的 .gnu.version-r 表):

而修改ELF内容之前是这样子的:

对比即可发现,该xgboost文件已经从引用glibc_2.14改为引用glibc_2.2.5了,到此,就可以在低版本的机器上运行分布式xgboost了,再次运行并查看日志如下:

所有机器都没有了本文档开头显示缺少GLIBC_2.14的错误提示了,程序成功运行!

我的总结:

解决该问题的办法比较通用,以后只要是在linux系统上出现了glibc版本不一致问题,都可以使用该方法解决。

注意

在有些文件使用readref –sV切换到16进制查看glibc_2.14起始位置的时候,并不一定是从每一行的第一个字节开始的,如下面这个例子:

上面这个文件的起始偏移量是0x011f88,打开该文件并使用十六进制查看之后,如下:

原始偏移量是011f88,加上0090得到glibc_2.14最终的16进制位置是12018,找到该位置,如下:

红线所示就是glibc_2.14的位置,蓝线所示就是glibc_2.2.5的位置,剩下的怎么修改,看上面的内容即可。

参考文档:

1:https://www.jianshu.com/p/7a75324e98ab  

程序破解及ELF文件格式分析

2:https://zohead.com/archives/mod-elf-glibc/   

Linux修改ELF解决glibc兼容性问题

3:http://kinva.cc/2017/03/20/GLIBC-2-14-not-found/ 

错误:/lib64/libc.so.6 version `GLIBC_2.14` not found解决办法

4:https://blog.blahgeek.com/glibc-and-symbol-versioning/              glibcSymbol Versioning和如何链接出低版本glibc可运行的程序

5:https://blog.csdn.net/wangmingsuyang/article/details/80089984          高版本glibc环境编译兼容低版本机器的.so文件

【注】:原创不易,转发请注明出处,谢谢!