17

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

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

我之前问过这个问题，但我认为我的帖子有点混乱。

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

文件结构（构建前）：

  • 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（这是练习的重点）。

检查节目： 看起来很接近（我宁愿有main.run，但我稍后会解决）。readelf -d
0x0000000000000001 (NEEDED) Shared library: [lib/foo.sh]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../../lib][foo.sh][lib/foo.sh]

AFAICT $ORIGINin-Wl,-rpath,'$ORIGIN/../../lib'意味着project/run/main.run这个 rpath 应该变成project/lib.

我试过$ORIGIN/..，，，，无济于事$ORIGIN/../lib。$ORIGIN/../..$ORIGIN/../../lib

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

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

4

2 回答 2

6

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

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

（你的 rpath 也是错误的。想一想：从 shell 中，如果你当前在你的可执行文件所在的目录中，你将如何到达你的库所在的目录？在这里，你需要cd ../lib。所以你的 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)
于 2011-06-10T20:22:36.380 回答
5

这是通过$ORIGIN在rpath.

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

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

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

文件结构（构建前）：

  • 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>到生成的库中。这应该与您在链接到此库时 为-lor选项提供的名称相匹配。-l:
  • -Wl,-rpath,'<PATH>'<PATH>作为运行时库搜索路径（或 rpath - 见上文）嵌入到生成的库中。
  • -L将路径添加到构建时库搜索路径列表。（注意：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) 搜索路径都是如此。

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

于 2011-06-12T16:56:39.993 回答