在构建依赖于它的程序后,如何更改共享库的文件名?

Zor*_*Hut 20 linux linker shared-libraries install-name-tool

我有一个程序依赖于它希望在目录结构内部找到的共享库.我想将该共享库移到更好的位置.在OS X上,可以使用install_name_tool完成此操作.我无法找到Linux的等价物.

作为参考,readelf -d myprogram吐出以下释义输出:

Dynamic section at offset 0x1e9ed4 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [this/is/terrible/library.so]
 0x00000001 (NEEDED)                     Shared library: [libGL.so.1]
 0x00000001 (NEEDED)                     Shared library: [libGLU.so.1]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
(continues in an uninteresting fashion)
Run Code Online (Sandbox Code Playgroud)

(并根据要求,ldd myprogram:)

    linux-gate.so.1 =>  (0x0056a000)
    this/is/terrible/library.so => not found
    libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x0017d000)
    libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00a9c000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00710000)
   (etc, etc)
Run Code Online (Sandbox Code Playgroud)

我想将"this/is/terrible/library.so"改为"shared/library.so".请注意,如果程序保留在其"构建"位置,其中/// ter//.实际存在的相对路径,则ldd能够找到它,正如您所期望的那样.

我知道RPATH并不是我想要的,我不需要在全球范围内改变搜索路径.

Ber*_*mos 13

我们可以使用patchelf:

patchelf --replace-needed liboriginal.so.1 libreplacement.so.1 my-program
Run Code Online (Sandbox Code Playgroud)

我们还可以删除依赖项:

patchelf --remove-needed libfoo.so.1 my-program
Run Code Online (Sandbox Code Playgroud)

添加依赖项:

patchelf --add-needed libfoo.so.1 my-program
Run Code Online (Sandbox Code Playgroud)

或者更改搜索库的路径(rpath):

patchelf --set-rpath /path/to/lib:/other/path my-program
Run Code Online (Sandbox Code Playgroud)


Zor*_*Hut 8

发布一个试探性的,可怕的,hacky解决方案.

库依赖项存储在称为.depends块的ELF块中.该块的格式是一大堆标识符/字符串指针对,其中stringpointer指向位于二进制文件中某个位置的标准C空终止字符串.

你知道这是怎么回事,对吗?

是的,只要您需要的新路径不大于旧路径,您就可以直接进入二进制文件并进行简单的字符串替换.确保不添加或删除字节,否则您将破坏整个二进制文件.如果你想对它更安全,你实际上可以遍历ELF结构以确保你有正确的位置 - 现在我只是检查以确保源字符串只显示一次.

ELF确实包含了一个校验和,但显然没有实际验证它的加载器,因此忽略它是"安全的" - 尽管是凌乱的.

"真正的解决方案"将是允许对ELF结构进行低级广义操纵的实用程序.尽管我可以说,除了一些特殊情况(主要是RPATH)之外,没有这样的实用程序存在.我不会假装知道这样的实用程序有多难写.

我绝对会喜欢这个更好的解决方案,但到目前为止,这似乎有效.


Dmi*_*kov 5

HT - 这可能会有所帮助.

HT是可执行文件的文件编辑器/查看器/分析器.目标是结合调试器的低级功能和IDE的可用性.我们计划实现所有(十六进制)编辑功能并支持最重要的文件格式.

我找不到与ZorbaTHut解决方案有很大不同的东西,但也许可以使用不同长度的名称并保持二进制有效.

gelf - 这也很有用.

GElf是一个通用的,与ELF类无关的API,用于处理ELF目标文件.GElf提供了一个用于处理32位和64位ELF格式目标文件的通用接口.

  • 更新:patchelf(http://nixos.org/patchelf.html)似乎是现在的方式. (8认同)
  • @hraban:现在有可能.检查我的答案 (2认同)