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，显示如下：
现在我们下面那行标红线的内容复制到上面同等位置，复制完后的内容如下：
再使用:%!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/ glibc和Symbol Versioning和如何链接出低版本glibc可运行的程序
5：https://blog.csdn.net/wangmingsuyang/article/details/80089984 高版本glibc环境编译兼容低版本机器的.so文件
【注】：原创不易，转发请注明出处，谢谢!