$ORIGIN/lib 是图书馆的合理 RUNPATH 吗？

Question

背景

我有一个具有这种结构的第三方库：

lib
 ├── liba.so
 └── libb.so // libb.so is NEEDED by liba.so

两者都将 RUNPATH 设置为 $ORIGIN/lib 并且 liba.so 取决于 libb.so。

在我的第一方项目中，我有以下结构：

bin
 ├── liba.so
 ├── libb.so
 └── myexecutable

其中 myexecutable 直接取决于 liba.so 和 libb.so。 liba.so 仍然直接依赖于 libb.so。 myexecutable 的 RUNPATH 是 $ORIGIN.

./myexecutable 可以解析 liba.so 因为 $ORIGIN/liba.so = <path-of-myexecutable>/liba.so = ./liba.so 存在
./liba.so 无法解析 libb.so，因为 $ORIGIN/lib/libb.so = <path-of-liba.so>/lib/libb.so = ./lib/libb.so 不存在。 这是使用 CMake 的 RUNTIME_DEPENDENCY_SET“自动”安装导入的库目标时出现的问题。

这是我的想法。

如果结构类似于：

案例：lib

.
├── lib
│   ├── liba.so
│   └── libb.so
└── myexecutable

executables 有一个 RUNPATH $ORIGIN/../lib 并且 libraries 有一个 RUNPATH $ORIGIN 如果结构是这样的：

案例bin+lib

.
├── bin
│   └── myexecutable
└── lib
    ├── liba.so
    └── libb.so

最后，executables 有一个 RUNPATH $ORIGIN 和 libraries 有一个 RUNPATH $ORIGIN 是有道理的如果结构是这样的：

案例：bin（我的用例）

bin
 ├── liba.so
 ├── libb.so
 └── myexecutable

在上述所有情况下，库的运行路径总是 $ORIGIN 而不是 $ORIGIN/lib。出于这个原因，将 $ORIGIN/lib 设置为共享对象文件的 RUNPATH 似乎是错误的，因为我无法构建任何最好将库 RUNPATH 设置为 $ORIGIN/lib.

的情况

问题

如果.so-来自同一个第三方库的文件应该在某个目录中并排存在，在存在必要的相互依赖性的情况下，一定不能 .so - 依赖于其他 .so 的文件 - 文件总是在它们的 RUNPATH 中有 $ORIGIN?

我知道这是我可以在实际图书馆的背景下与第三方图书馆作者进行的讨论 - 我是，但我也相信我的问题是其他人会从上下文中受益的问题除了我用例中的库之外的其他库。

Answer 1

If .so-files from the same third-party library are expected to live side-by-side in some directory, in presence of NEEDED inter-dependencies, mustn't the .so-files with dependencies on other .so-files always have $ORIGIN in their RUNPATH?

是的。

使用 RUNPATH 或 $ORIGIN/lib 构建它们的 3d 派对供应商不知道 he/she 在做什么。

$ORIGIN/lib 是图书馆的合理 RUNPATH 吗？

Is $ORIGIN/lib a reasonable RUNPATH for libraries?

c++

linux

shared-libraries

dynamic-linking

背景

这是我的想法。

问题