问题标签 [rpath]

如果我在这里遗漏了一些明显的东西，请原谅我。我正在为另一个平台开发一些应用程序，并且我所有的专有库都安装到 /app/lib。为了促进这一点，我为我的每个二进制文件指定了一个运行时库路径作为“/app/lib”。这很好用；但是，它要求在链接时路径“/app/lib”存在于我的构建环境中（即使该目录为空）。我正在使用 NetBeans，这可能会使事情复杂化，但我可以看到“-Wl，-rpath /app/lib”被传递给 gcc。

我想避免在我的构建环境中创建一个空的“/app/lib”，但我不想更改目标平台上的文件结构。如果我从构建环境中删除 /app/lib，则在构建时会出现错误，无法找到它。有没有办法指定运行时搜索路径而不需要它在链接时存在？

我有一个可执行文件，它隐式加载了几个 .so 库，它们都是由我构建的。对于部署，或者至少是测试/调试，我希望将它们全部放在同一个目录中：

为了让可执行文件隐式加载库，我想为可执行文件的目录设置一个 rpath (DT_RUNPATH)。对于 OS X，我会这样做：

请注意@loader_path/.在 OS X 中形成可执行文件的 rpath。对于 Linux，我能做到的最接近的是

这里的问题是，在 Linux 上，rpath 遵循当前工作目录，而不是可执行文件的目录。有没有办法在 Linux 上完成同样的事情？

我必须提供一个带有应用程序的第三方库。因为我不想LD_LIBRARY_PATH手动设置或需要任何包装脚本，所以我希望 automake 设置自定义rpath. 不幸的是libtool，它有自己的-rpath选择，并且只添加-Wl,-rpath,/foo/bar到LDFLAGS结果

因为libtool似乎对命令行选项感到困惑。替代形式也是如此-Wl,-rpath -Wl,/foo/bar。

有没有办法在没有 libtool 干扰的情况下指定自定义 rpath？

我有一个应用程序，调用它Animal.app。在它的Contents/Frameworks文件夹里面是一个框架，比如说Mammal.framework. 在框架的Versions/A/Frameworks文件夹中，我有dog.dylib. 的安装名称dog.dylib是@rpath/dog.dylib。对于"Runpath Search Paths"框架的设置，我已经指定了@loader_path/../Frameworks. （我对最后一个设置的推理是 dylib 的“加载器”将是框架的二进制文件，位于路径Mammal.framework/Versions/A/Mammal。）

我在运行时收到一条错误消息：

我已经阅读了 Apple 的“Run-Path Dependent Libraries”文档和 Mike Ash 在 上的博客文章@rpath，但我仍然看不出我做错了什么。

本质上，我正在寻找这个问题的答案：有没有办法检查 Linux 上的当前 rpath？，但对于 OSX。我想以编程方式获取 OSX 中当前进程的 RPATH 条目。我知道如何使用 shell 来做到这一点，但我正在寻找一种方法来内部检查我的进程。

谢谢！

我正在制作一个使用很多自己的共享库的项目；我的意图是在目录中创建一个库名称，因此，例如，代替 -lfoo（查找 /usr/lib/libfoo.so 或 /opt/lib/libfoo.so 等），我将使用 -lfoo /bar（查找 /usr/lib/libfoo/bar.so 或 /opt/lib/libfoo/bar.so 等）。

我做了一个真正的小代码来测试：

并将其编译为：gcc -fPIC -shared -Wl,-rpath,libfoo/ lib.c -o /usr/lib/libfoo/bar.so.

然后，在测试程序中，我使用gcc -lfoo/bar test.c，它编译（它mylib()从我的库中找到符号），但是当我尝试运行程序 ( ./a.out) 时，动态链接器抱怨它找不到库。就我而言，使用 Mac OS X Lion：

我究竟做错了什么？也许答案是“一切”，所以......我应该如何达到预期的效果，在库路径上寻找 libfoo/bar.so 而不是 libfoo.so？

提前致谢。:)

考虑我有一个 ELF 共享库liba.so，它导出一个符号from_a。的实现from_a是根据一个符号定义的from_b，它是从共享库中导出的libb.so，并且liba.so有一个 DT_NEEDED 条目libb.so。

我现在有了program，它使用了 符号from_a。当我链接 时program，我-la会在链接行中包含链接器查找所需的任何链接时间搜索路径（如果有）liba.so。libb.so对in 中的符号没有直接依赖关系program。

第一个问题：是否保证（在可移植到所有使用系统的非损坏 ELF 的意义上）我不需要在链接行上列出间接依赖项（在这种情况下libb.so）？我相信这是真的，但我想确认一下。链接器的这种行为是由任何规范规定的吗？如果是这样，哪一个（ELF规范？）liba.soprogram

第二个问题：如果liba.so和libb.so安装在不默认搜索的非标准位置（比如 $HOME/lib，而不是 /usr/lib），那么在链接时program，BFD 链接器，至少在我当前的系统和尽管库安装目录是用 -L 指定的，并建议使用or ，但我测试过的其他人很少会抱怨libb.so找不到。但是，如果标识安装位置的 RPATH 或 RUNPATH 设置在 中，则 BFD 链接器将被放置。如果没有直接依赖，为什么 BFD 链接器关心是否可以在链接时找到？是通过将 RPATH 设置为 on 获得的行为-rpath-rpath-linkliba.solibb.soprogramliba.so保证？依靠它来安抚链接器会很好。我还注意到在这种情况下黄金链接器不会失败。这里的预期行为是什么？

我正在尝试编译 NTL 库（主机是 64 位，但目标平台是 32），但我在使用 libtool 时遇到了一些问题。可以在此pastebin中找到该命令以及输出。我知道我在结构上做错了rpath，但我对它不太熟悉，无法确切知道是什么。有什么帮助吗？

编辑：配置运行为：

./configure CC=/tmp/ntl-build/bin/arm-linux-androideabi-gcc CXX=/tmp/ntl-build/bin/arm-linux-androideabi-g++ SHARED=on AR=/tmp/ntl-build /bin/arm-linux-androideabi-ar RANLIB=/tmp/ntl-build/bin/arm-linux-androideabi-ranlib NTL_GMP_LIP=on GMP_PREFIX=/prod/android-ndk-r8/workspace/verifiable/gmp-precompiled/ armeabi-v7a DEF_PREFIX=/tmp/ntl-build/install_dir

gcc-4.7.2我在我的环境中定制了。系统 gcc 是gcc-4.3.4.

我已经为我的所有自定义 gcc 的二进制文件和共享库修补了RUNPATH ，使用patchelf --set-rpath

但是，当我ldd在 4.7.2 上运行时，cc1它会选择系统而不是RUNPATHlibstdc++指向的系统：

可以看出，RUNPATH指定了gcc-4.7.2库位置：

我知道它libstdc++.so.6存在于RUNPATH的第一个条目中：

我的环境中没有设置LD_LIBRARY_PATH：

• 为什么它不选择在RUNPATH中找到的库？
• 如何强制它使用gcc-4.7.2库？

我正在修改一个与Automake / libtool文档提供的示例非常相似的项目。摘录：

顶级configure.ac：

顶级 Makefile.am：

./src生成文件.am：

在我的包创建软件提供的 fakeroot 环境中，我执行以下命令

在所有三个 *.la 文件中，libdir='/usr/lib'：

• /src/libname.la
• /src/.libs/libname.la
• /usr/lib/libname.la

我知道为 /src/progname 设置了 RPATH 以允许在 make 之后直接执行。但是我的印象是，在安装规则期间，libtool 会删除这个临时 RPATH 并将其替换为 libdir（如上指定的“/usr/lib”以进行配置）。此外，如果系统的 ld.so 搜索路径中存在 libdir，则现代 libtool 版本实际上会删除 RPATH。

为什么这没有发生？就目前而言，临时 RPATH 目录存在安全风险，允许任何人从 /src/.libs 加载恶意 libname.so。

Fedora RPath 打包草案包含一些删除 RPATH 的有用建议，但是我更喜欢在 Autotools 框架内工作的答案。