构建一个使用 ld 选项 -rpath 和 $ORIGIN 的简单（hello-world-esque）示例

Question

注意：下面是完整的工作示例。原始问题如下：

我在使用 ld 的 -rpath 参数和 $ORIGIN 时遇到问题。
由于找不到完整的示例，我想我会尝试自己写一个，以便我和其他人以后可以使用它。一旦我得到它的工作，我会整理它。

我asked about this before，但我觉得我的帖子有点混乱。

示例项目构建了一个共享库和一个链接到该库的可执行文件。
它非常小（3 个文件，22 行，包括构建脚本）。
您可以从here下载项目

---

文件结构（构建前）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • make.sh

---

project/src/foo.cpp

int foo()
  { return 3; }

project/src/main.cpp

int foo();

#include <iostream>
int main()
  {
    std::cout << foo() << std::endl;
    return 0;
  }

project/make.sh

# Make directories:
mkdir -p -v obj
mkdir -p -v lib
mkdir -p -v run

# Build the library:
g++ -c -o obj/foo.o src/foo.cpp -fPIC
g++ -shared -o lib/foo.sh obj/foo.o

# Build the executable:
g++ -c -o obj/main.o src/main.cpp
g++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../../lib' -Llib -l:foo.sh

---

从project 目录，运行make.sh（确保它是可执行的）。

---

文件结构（构建后）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • obj/
    • foo.o
    • main.o
  • lib/
    • foo.so
  • run/
    • main.run
  • make.sh

---

run/main.run 现在应该在执行时从任何地方加载lib/foo.sh。

问题

目前，这仅部分有效。
文件编译和链接正常，但从除project 以外的任何目录运行时链接失败（这是练习的重点）。

用readelf -d检查main.run显示：
0x0000000000000001 (NEEDED) Shared library: [lib/foo.sh]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../../lib] 看起来很接近（我宁愿拥有[foo.sh] 而不是[lib/foo.sh]，但我稍后会修复它）。

AFAICT -Wl,-rpath,'$ORIGIN/../../lib' 中的 $ORIGIN 表示 project/run/main.run 所以这个 rpath 应该变成 project/lib。

我尝试了$ORIGIN/..、$ORIGIN/../lib、$ORIGIN/../..、$ORIGIN/../../lib 无济于事。

注意：我使用的是-l:，它需要完整的库文件名（除其他原因外，当所有函数采用相同的名称格式时，使用变量编写脚本更容易）。

有谁知道为什么这不起作用？
或者，是否有人拥有或知道完整的工作示例？

Answer 1

（我宁愿拥有[foo.sh] 而不是[lib/foo.sh]，但我稍后会解决这个问题）。

您的大部分问题是：名称中的 / 阻止了动态链接器执行 rpath 魔术。

(你的 rpath 也是错误的。想想看：从 shell 中，如果你当前在你的可执行文件所在的目录中，你将如何到达你的库所在的目录？在这里，你需要 @ 987654324@。所以你的rpath应该是$ORIGIN/../lib。）

如果您将对象构建为libfoo.so 并与-Llib -lfoo 链接，则链接器将计算出您的意图，并做正确的事情。但是，如果您要使用不寻常的命名约定，则必须提供帮助：

1. 更改库的链接行，将库的 SONAME 显式设置为 foo.sh：

   g++ -shared -Wl,-soname,foo.sh -o lib/foo.sh obj/foo.o

2. 修复rpath：

   g++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../lib' -Llib -l:foo.sh

运行ldd main/main.run 以查看发生了什么非常有用。在您最初的失败案例中，您会看到如下内容：

    lib/foo.sh (0xNNNNNNNN)

（缺少任何=> /some/resolved/path 表明它没有完成任何路径解析）。在固定情况下，您会看到如下内容：

    foo.sh => /your/path/to/run/../lib/foo.sh (0xNNNNNNNN)

Answer 2

这是在rpath 中使用$ORIGIN 的相对路径链接（使用ld）示例。

rpath 是嵌入在二进制文件（共享库 (.so) 和可执行文件）中的路径（或路径集）。
这些路径是二进制文件在运行时必须链接的共享库的首要搜索路径。

$ORIGIN 是 rpath 路径的潜在起始目录。 它解析到包含执行文件的目录。 （例如：$ORIGIN/lib）

示例项目构建了一个共享库和一个使用rpath 和$ORIGIN 链接到该库的可执行文件。
你可以从here下载项目。

---

文件结构（构建前）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • make.sh

---

project/src/foo.cpp

int foo()
  { return 3; }

project/src/main.cpp

int foo();

#include <iostream>
int main()
  {
    std::cout << foo() << std::endl;
    return 0;
  }

project/make.sh

# Make directories:
mkdir -p -v obj
mkdir -p -v lib/dir
mkdir -p -v run

# Build the library:
g++ -c -o obj/foo.o src/foo.cpp -fPIC
g++ -shared -o lib/dir/foo.so -Wl,-soname,foo.so obj/foo.o

# Build the executable:
g++ -c -o obj/main.o src/main.cpp
g++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../lib/dir' -Llib/dir -l:foo.so

---

从project 目录，运行make.sh（如果不运行，确保make.sh 具有执行权限）。

如果一切顺利，main.run 现在应该在执行时加载lib/dir/foo.so，无论project 的绝对路径如何（您可以将其移动到任何地方），也无论当前工作目录如何（您可以运行它从任何地方）。

---

注意事项：

• -fPIC 指示编译器构建可重定位的目标文件（构建到共享库中的目标文件必须是可重定位的）。
• -Wl,-soname,<NAME> 将 <NAME> 嵌入到生成的库中。这应该与您在链接到此库时为 -l 或 -l: 选项提供的名称相匹配。
• -Wl,-rpath,'<PATH>' 将 <PATH> 作为运行时库搜索路径（或 rpath - 见上文）嵌入到生成的库中。
• -L 将路径添加到 build-time 库搜索路径列表。 （注意：rpath 在构建时不相关，-L 在运行时不相关）。
• -l: 添加要链接的库的文件名（不带路径）。 （类似于-l，除了-l: 需要完整的文件名。

---

文件结构（构建后）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • obj/
    • foo.o
    • main.o
  • lib/
    • dir/
      • foo.so
  • run/
    • main.run
  • make.sh

---

注意：我使用的是-l:，它需要完整的库文件名（除其他原因外，当所有函数采用相同的名称格式时，使用变量编写脚本更容易）。
更常见的是使用-l，其中-l<NAME> 表示lib.so。

限制

据我所知（如果我错了，请纠正我）没有办法在搜索路径的子目录中添加库（除了将该目录添加为子路径）。这适用于构建时 (-L) 和运行时 (-rpath) 搜索路径。

因此，如果您有两个名称相同但位置不同的库，您将无法将它们都链接起来。 （我希望我是错的或者这得到了解决）。