☰

如何使 RPATH 中的 $ORIGIN 不遵循符号链接？

tag-icon • tag-icon symlink dynamic-linking elf
如何使 RPATH 中的 $ORIGIN 不遵循符号链接？

我有一个可执行文件app，它依赖于一个库并通过如下方式libbar.so加载它：RPATH$ORIGIN

$ readelf -d app

Dynamic section at offset 0xe08 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libbar.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/lib/]

最好在适当的目录结构中运行它，该目录结构由可执行文件的符号链接和libbar.so：

$ ls -R
.:
app@  lib/

./lib:
libbar.so@

- 但链接器遵循到可执行文件的原始文件的符号链接，设置$ORIGIN为可执行文件的目录并从那里解析依赖路径。有没有可能让它不这样做？因此，在目录路径方面，在搜索 lib 文件时，符号链接被视为文件系统的真实文件（搜索的“端点”）。

另外，针对这个问题的一些推理：

  1. 将二进制文件设置为很方便在几个关系目录中搜索依赖项，例如在$ORIGIN/二进制文件本身的 和$ORIGIN/appname_dependencies/(这样人们可以将二进制文件及其依赖项复制到一个目录中并运行它，但也可以使用多个版本的更复杂的设置进行回退系统中相同的二进制文件）。

  2. 由于要求几个依赖搜索路径，RPATH是使用的搜索方法：依赖项 ( ) 的“斜线”名称NEEDED Shared library: [./libbar.so]仅设置 1 个搜索路径。此外，为了简单起见，依赖关系解析路径应该位于二进制文件本身中。

  3. 能够将所有二进制文件（应用程序及其所有依赖项）合并到带有链接的完整依赖图，而不是复制文件。和符号链接更有弹性比硬链接：它们跨文件系统链接。事实上，我在一个linux集群的学术环境中遇到了这个问题，无法完成到父目录的硬链接：

        $ ln ../afile 
    ln: creating hard link `./afile' => `../afile': Invalid cross-device link

答案1

如果你真的想要混合这样的符号链接，你可以构建如下配置：

  • 将可执行文件移至其自己的目录
  • 建立从“正常”位置到移动的可执行文件的符号链接
  • 在可执行文件的目录中创建指向要解析的共享库的符号链接

相关内容