Arch Linux

jingmouren

会员

注册时间： 2014-09-13

帖子： 112

patchelf工具对python包的.so不起效

云端的Centos的GLIBC版本比较老
https://blog.csdn.net/qq_33873431/artic … s/97751520
类似的问题如上链接给出的解决方案是patchelf --add-needed *.*.so.6 *.so

我现在的问题是python的tensorflow包用了这个patchelf修改了.so的依赖路径仍然报错
/lib64/libm.so.6: version `GLIBC_2.23' not found (required by ***/anaconda3/lib/python3.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
该如何处理？

依云

会员

所在地： a.k.a. 百合仙子

注册时间： 2011-08-21

帖子： 8,919

个人网站

Re: patchelf工具对python包的.so不起效

毫无上下文。链接不相关。

你做了什么？
你遇到了什么问题？

jingmouren

会员

注册时间： 2014-09-13

帖子： 112

Re: patchelf工具对python包的.so不起效

python
>>import package

提示错误
/lib64/libm.so.6: version `GLIBC_2.23' not found (required by ***/anaconda3/lib/python3.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)

我在/opt安装了glibc-2.25
再用patchelf修改_pywrap_tensorflow_internal.so的libm.so.6为/opt/glibc-2.25/lib/libm.so.6
然后再重新进python和import
还是同样的/lib64/libm.so.6 GLIBC_2.23的错误

依云

会员

所在地： a.k.a. 百合仙子

注册时间： 2011-08-21

帖子： 8,919

个人网站

Re: patchelf工具对python包的.so不起效

1. 你的 libm.so.6 为什么没有 GLIBC_2.23？pacman -Qkk glibc 看看
2. 你为什么不用 Arch 官方源里的 Python 呢？

依云

会员

所在地： a.k.a. 百合仙子

注册时间： 2011-08-21

帖子： 8,919

个人网站

Re: patchelf工具对python包的.so不起效

哦，你的意思是，你在 CentOS 上跑这个东西？你的罕见用语（「云端」）让我理解错了。「云端」也是一款软件的名字。

这种情况下，用 LD_LIBRARY_PATH 指向新的 glibc 库目录吧。头疼……不如试试 docker、lxc 啥的。

jingmouren

会员

注册时间： 2014-09-13

帖子： 112

Re: patchelf工具对python包的.so不起效

哦，你的意思是，你在 CentOS 上跑这个东西？你的罕见用语（「云端」）让我理解错了。「云端」也是一款软件的名字。

这种情况下，用 LD_LIBRARY_PATH 指向新的 glibc 库目录吧。头疼……不如试试 docker、lxc 啥的。

docker可以运行
而改LD_LIBRARY_PATH会报 37408:    __vdso_time段错误(吐核)
主要是搜到网上解决这个GLIBC的办法都说patchelf，但通过python再调用的却没进一步讨论，怀疑是启动python的那步已经加载了libm.so.6等，所以光改库里的.so的rpath没用，但没搜到整体修改方案

最近编辑记录 jingmouren (2020-07-09 20:16:09)

依云

会员

所在地： a.k.a. 百合仙子

注册时间： 2011-08-21

帖子： 8,919

个人网站

Re: patchelf工具对python包的.so不起效

docker可以运行
而改LD_LIBRARY_PATH会报 37408:    __vdso_time段错误(吐核)
主要是搜到网上解决这个GLIBC的办法都说patchelf，但通过python再调用的却没进一步讨论，怀疑是启动python的那步已经加载了libm.so.6等，所以光改库里的.so的rpath没用，但没搜到整体修改方案

别怀疑了，libm 这么广泛使用的库，你只改一个 so 哪里够啊。整体的方案就是 LD_PRELOAD，但你这是在旧系统上跑新代码，指不定有多少库太旧了呢。挺容易出事的，所以 docker 能用就用它就好啦。