我有一个 c++ 共享库，作为其正常行为的一部分 fork()/execs() 另一个包含一些不稳定遗留代码的可执行文件。除了这个库之外，这个可执行文件没有用，所以我想避免将它放在 PATH 目录中。我还希望能够在不同位置安装多个副本，因此不希望使用硬编码路径。是否有任何相当于 RPATH 的东西可以让 exec() 找到这个可执行文件？或者，是否可以从库本身查询共享库的 rpath？

编辑：这篇文章表明后者是可能的。如果有人知道所提问题的答案，我将保持开放状态。有没有办法检查 Linux 上的当前 rpath？

i am trying ...

but getting error, that existingpackage is not defined

我使用 google-perf 工具 (tcmalloc) 库编译了 Python 2.6.6，以消除我在使用默认 2.6.5 时遇到的一些内存问题。在获得 2.6.6 之后，它似乎无法正常工作，因为我认为 Ubuntu 中的默认 2.6.5 安装存在问题。从软件频道安装的所有二进制文件（如 wxPython 和 setuptools）都不能在 2.6.6 中正常工作。这些需要重新编译吗？使其顺利运行的任何其他建议。我仍然可以在不更改路径的情况下将 2.6.5 设置为默认值吗？该路径首先在 usr/local/bin 中查找。

我正在尝试将基于 libtool 的包合并到我自己的项目中，可能是以非标准方式。这是我的目标：

1. 构建外部项目：

   /li>

2. 在运行时构建我自己的项目，该项目依赖于外部项目的共享库和可执行文件：

   /li>

3. 将所有内容打包成一个“本地化”压缩包......也就是说，虽然我在$HOME/blah构建主机上拥有所有内容，但我希望能够将压缩包解压缩到任何任意目录（在其他主机上），而不必与我的环境混为一谈。目的是允许我的项目的多个版本并排共存，而不会出现任何令人讨厌的“异花授粉”。

我知道我可以-rpath '$ORIGIN/../lib'在我的项目中使用它来确保始终在运行时加载正确的共享库。但是，似乎 libtool 坚持-rpath根据 的确切路径分配自己的设置$HOME/blah/lib，如果我碰巧将所有内容解压缩到不同的目录（例如，$HOME/blah.2011-06-02），则会中断。

有没有办法绕过这个限制？我看到debian 和 libtool 人员之间就该主题进行了相当冗长的 rpath 讨论，但除了“我们不同意”之外，它有些陈旧且不确定。

我正在尝试学习如何使用-rpathGCC 的链接器（ld）中的选项$ORIGIN。

我正在尝试我能想到的最简单的例子（见下文），我阅读的所有链接似乎都说我做得正确。

但是，当我运行可执行文件时，它找不到共享对象，除非我从$ORIGIN.

在可执行文件（main.run）上使用 readelf -d 显示：

文件结构（相关文件）为：

• /make/test/dll_test/
  • main.run
  • lib/
    • foo.so

从 dll_test 中执行工作正常。从其他地方（/make/test）执行会出现错误：

dll_test/main.run：加载共享库时出错：lib/foo.so：无法打开共享对象文件：没有这样的文件或目录

我正在使用-l:foo.so而不是-lfoo，但这不应该影响任何事情（我希望）。

源文件

dll_test/src/foo.cpp

dll_test/src/main.cpp

构建脚本

dll_test/make.sh

要进行构建，请在它们各自的位置创建这些文件，然后从 dll_test（或项目根目录所在的任何位置）中简单地运行“sh make.sh”。它应该生成“dll_test/main.run”。

从 dll_test 中运行“main.run”应该可以工作（打印 1）。
从 dll_test 中运行“main.run”失败。为什么？

此外，foo.so 的路径存储在 main.run 作为 [lib/foo.so]。我可以让它成为 [foo.so] 以便我可以使用 -Wl,-rpath,'$ORIGIN/lib' 吗？

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

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

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

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

文件结构（构建前）：

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

project/src/foo.cpp

project/src/main.cpp

project/make.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:它需要完整的库文件名（除其他原因外，当所有函数采用相同的名称格式时，使用变量编写脚本更容易）。

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

我只是在这里做了一个使用 ld-rpath选项的基本示例（有关工作版本，请参阅第二个响应）。我正在尝试创建一个示例，其中链接到，然后链接到，全部使用and 。$ORIGIN main.runfoo.sobar.sorpath$ORIGIN

运行时文件结构是：

• 项目/
  • 库/
    • 目录/
      • 子/
        • 吧.so
      • foo.so
  • 跑/
    • main.run（构建失败）

我正在构建 foo.so 使用：

哪个构建得很好。ldd lib/dir/foo.so甚至可以找到bar.so。

但是，当我尝试链接main.run到时foo.so，foo.so找不到 bar.so。

我正在构建 main.so 使用：

foo.so如果使用不递归链接的另一个版本，这很好用。（在下面的项目中取消注释 make.sh 中的行以进行测试）。

但是，使用正常foo.so我在构建时遇到此错误main.run：

/usr/bin/ld：警告：bar.so，lib/dir/foo.so 需要，未找到（尝试使用 -rpath 或 -rpath-link）

所以我的问题是：

1. 在 foo.so 内是否$ORIGIN解析为project/lib/dir(where foo.sois) 或project/run(where main.run(the executable linking it) is)？
   ldd 似乎表明它是project/lib/dir，这似乎是最好的方法（尽管我尝试假设两者）。
2. 我如何让这些链接（同时保留可重定位性） - 最好不使用-rpath-link.

您可以在此处下载该项目。这就像我能做到的一样简单。4 个短源和一个脚本。
提取后，只需./make.sh从内部运行project/。

注意：我正在使用-l:. 这不应该改变任何东西，除了库被命名为 likefoo.so而不是，并且与而不是libfoo.solunk 。-l:foo.so-lfoo

我有一个二进制“CeeloPartyServer”，它需要在运行时在 FreeBSD 机器上找到 libFoundation.so。它们都在同一个目录中。我使用链接器标志（在另一个平台上，使用交叉编译器）编译 CeeloPartyServer -rpath=$ORIGIN。

为什么我尝试运行它时找不到库？

我的确切链接器行是：-lm -lmysql -rpath=$ORIGIN.

我很确定我不必转义 $ 或类似的东西，因为我的 readelf 分析确实表明库 rpath 设置为 $ORIGIN。我错过了什么？

我正在使用启用了 setcap CAP_NET_RAW 的 python。我的 python 脚本导入了一个共享库，它的 RPATH 中有 $ORIGIN。由于我的 python 现在是一个 suid 应用程序，$ORIGIN 没有被评估并且库没有正确加载（这是由于glibc 中发现的安全漏洞）。有没有办法告诉链接器我的库路径是安全的并仍然加载库？

还有一些注意事项：

1. 我只在开发阶段需要这个功能。我不是在寻找生产解决方案。
2. 以 root 身份工作时，一切正常。
3. 我不想以 root 身份工作。

谢谢，戴夫

为方便起见，我在下面添加了相关的联机帮助页。

我的（错误）理解首先：如果我需要用 分隔选项,，这意味着第二个-Wl不是另一个选项，因为它出现在它之前,，这意味着它是-rpath选项的一个参数。

我不明白怎么-rpath可能有-Wl,.争论！

在我看来，这将是有意义的：

这应该-rpath使用当前目录参数调用链接器选项。

男人 gcc：

-Wl，选项

将选项作为选项传递给链接器。如果 option 包含逗号，则在逗号处将其拆分为多个选项。您可以使用此语法将参数传递给选项。例如，-Wl,-Map,output.map传递 -Map output.map给链接器。使用 GNU 链接器时，您也可以使用 `-Wl,-Map=output.map' 获得相同的效果。

男人ld：

-rpath=目录

将目录添加到运行时库搜索路径。这在将 ELF 可执行文件与共享对象链接时使用。所有 -rpath 参数都连接起来并传递给运行时链接器，运行时链接器使用它们在运行时定位共享对象。-rpath 选项也用于定位明确包含在链接中的共享对象所需的共享对象；