![使用 patchelf 修补库后 ldconfig 创建具有奇怪名称的链接?](https://linux22.com/image/162992/%E4%BD%BF%E7%94%A8%20patchelf%20%E4%BF%AE%E8%A1%A5%E5%BA%93%E5%90%8E%20ldconfig%20%E5%88%9B%E5%BB%BA%E5%85%B7%E6%9C%89%E5%A5%87%E6%80%AA%E5%90%8D%E7%A7%B0%E7%9A%84%E9%93%BE%E6%8E%A5%EF%BC%9F.png)
我正在修补我的开发服务器上的几个库,以使用该patchelf
工具删除不需要的依赖项。它们被打包成 RPM 并安装在我的运行时系统上。安装后,ldconfig
被调用,并创建奇怪的链接。
运行时系统上修补的库的位置类似于/usr1/blah/lib
几个子文件夹。该位置和子文件夹的位置在我的/etc/ld.so.conf
文件中指定。当我运行时ldconfig
,会创建一堆名称奇怪的链接,例如:
?N -> libFoo.so
??r? -> libBar.so
以及名称是库中函数的部分函数名称的链接,例如,如果我这样做objdump -x
并查看函数名称,则链接将将该函数的一部分作为其名称。
我的理解是 ldconfig 查看SONAME
库的名称并创建具有该名称的链接。然而,当我objdump -x
对所有受影响的库进行 an 操作并 grep for时SONAME
,没有什么异常,它们都以 .so 结尾,并且没有任何奇怪的问号。
ldconfig -v
没有提供任何有用的信息。
关于可能发生的事情有什么想法吗?也许SONAME
我错过了某种方式搞砸了?谢谢你的帮助。
编辑:如果我只是删除依赖项作为修补过程的一部分(例如仅调用patchelf --remove-needed <dependency> <lib name>
,则不会发生此问题。只有当我使用该--add-needed
标志时才会发生此问题。
编辑2:如果我只是添加和删除垃圾依赖项(例如patchelf --add-needed garbage libFoo.so
紧随其后patchelf --remove-needed garbage libFoo.so
),这也会导致奇怪的链接问题。每个库中的最终依赖项列表是完全相同的,并且当我只使用该--remove-needed
标志时它就可以工作,这使我认为问题在于该--add-needed
标志以及patchelf
它执行此操作时对标头所做的任何操作。
编辑 3:此时我假设这是 patchelf 或 ldconfig 的错误。我猜是后者,因为我们使用的glibc
是 2012 年左右的版本 2.17,但是patchelf
.也许ELF标准已经改变了。
tl;dr 在 patchelf 版本 0.10 和 glibc 版本 2.17 中, --add-needed 选项似乎与 ELF 混淆,导致 ldconfig 创建一些不稳定的链接。
答案1
ldconfig
不仅足够聪明,可以在更改某些部分(特别是添加/更改/删除 soname 或 rpath)后正确读取 ELF 格式。
虽然库本身完全没问题,但这只是ldconfig
问题所在。