【问题标题】:How is the rpath resolved when the application is started via a symlink通过符号链接启动应用程序时如何解析 rpath
【发布时间】:2015-12-17 10:43:16
【问题描述】:

我在 Linux 系统上使用 rpath 设置和符号链接时遇到了这个问题。为了解释这个问题,我考虑了以下设置:

我有一个名为foo 的应用程序取决于libbar.so。该应用程序驻留在$ROOT/pkgs/foo-1.0/bin/ 并符号链接到$ROOT/bin/。图书馆libbar.so 住在$ROOT/lib/。这给出了以下结构:

$ROOT/
  bin/
   foo --> $ROOT/pkgs/foo-1.0/bin/foo
  lib/
   libbar.so
  pkgs/
   foo-1.0/
    bin/
     foo

应用程序foo 现在(以防止 LD_LIBRARY_PATH 设置)将rpath 设置为$ORIGIN/lib

现在的问题是$ORIGIN/lib 是针对已解析的符号链接解决的,而不是针对调用应用程序的路径 ($ROOT/bin)。 如何更改?

一种可能的解决方案是切换到硬链接,这在这种情况下有效,但我不能确保链接不指向文件系统边界,文件系统也不支持硬链接。

【问题讨论】:

  • 您需要将 rpath 设置为 $ORIGIN/../../../lib 或者您需要将$ROOT/pkgs/foo-1.0/lib 设为$ROOT/lib/ 的符号链接并使用 rpath $ORIGIN/../lib,或者使 $ROOT/bin/foo 成为设置 LD_LIBRARY_PATH 的 shell 脚本。 (无论您是否有来自 $ROOT/bin/ 的符号链接,$ORIGIN/lib 在您的任何情况下都不起作用)
  • $ROOT/lib 符号链接到$ROOT/pkgs/foo-1.0/lib 对我来说不是一个选项。因为我的一些应用程序出现了这个问题,在$ROOT/pkgs/foo-1.0/lib 中带来了他们自己的共享对象,并且它们也链接到$ROOT/lib

标签: linux shared-libraries symlink ld


【解决方案1】:

现在的问题是$ORIGIN/lib 已解决 到已解析的符号链接,而不是相对于从哪里开始的路径 应用程序被调用 ($ROOT/bin)。 怎么可能 这个要改吗?

由于动态链接加载器ld.so 解析运行时搜索路径的可执行文件不知道应用程序所在符号链接的路径,因此您的具体问题的答案是: 没办法。
除此之外,nos 在他的评论中提到了可行的解决方案:您需要将 rpath 设置为 $ORIGIN/../../../lib ...,或者将 $ROOT/bin/foo 设置为设置 @ 987654325@.

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-05-09
    • 2015-02-15
    • 2011-11-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多