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.14和Glibc_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，显示如下：