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,不然它找不到就会报错。