如何使用 $ORIGIN 获取 RPATH 以在 Code::Blocks GCC 上工作？答案

【问题标题】：How to get RPATH with $ORIGIN to work on Code::Blocks GCC?如何使用 $ORIGIN 获取 RPATH 以在 Code::Blocks GCC 上工作？
【发布时间】：2008-10-23 16:15:35
【问题描述】：

我正在尝试将包含特殊字符串 $ORIGIN 的 RPATH 链接到使用 GCC 和 Code::Blocks IDE 构建的可执行文件中。我已经指定了

-Wl,-R$ORIGIN

在项目的链接器选项中，但是到 GCC 的命令行输出是错误的（为了清楚起见已删除）：

g++ -Wl,-R

为 Code::Blocks 指定此参数的正确方法是什么？

【问题讨论】：

与 Code::Blocks: stackoverflow.com/q/6324131/257299 相关，但不是特定的

标签： command-line gcc linker codeblocks rpath

【解决方案1】：

决定制作令牌 $ORIGIN 的人是一个邪恶的混蛋，应该在程序员地狱中占有一席之地。由于 '$' 是 bash 和其他脚本语言（如 make）的特殊字符，因此除非小心转义，否则它会搞砸一切。更糟糕的是，根据您使用的构建环境，如何正确逃逸的细节可能会发生变化。

在 bash 中，您需要在 $: 前面加上一个反斜杠：

-Wl,-R\$ORIGIN

Code::Blocks 显然也将 $ 视为特殊的。然后，无论子进程控制器 Code::Blocks 发送命令以将反斜杠视为特殊字符。因此，反斜杠和 $ 都需要加倍才能正确转义。因此，在 Code::Blocks 链接器设置中，需要指定：

-Wl,-R\\$$ORIGIN

...输出：

-Wl,-R\\$ORIGIN

...到构建日志，但实际上发送了 shell：

-Wl,-R\$ORIGIN

...如上所述会产生预期的结果。

好痛。

【讨论】：

+1 只是为了邪恶的混蛋评论......这个问题给我带来了很多痛苦
完美的评论，他应该在地狱里腐烂......有40个魅魔在试探他哈哈。
有没有办法，给定一个构建的可执行文件，改变它的 RPATH？由于这只是 ELF 表中的一个字符串，因此看起来并不无道理。在我看来，将 rpath 设置为 $ORIGIN/yada/yada 似乎是您想要添加到一些现有（可能非常复杂）构建脚本的东西，如果它们提供了一种将选项发送到链接器的方法，那么很好，但是，正如所讨论的，你必须处理逃生地狱（可能更容易制作你自己的'ld'包装器来偷偷溜进去）。 OTOH 在烟雾清除后修改结果上的 rpaths？没那么难。也就是说，如果有一个实用程序可以做到这一点......
export ORIGIN='$ORIGIN' 以防万一？
我必须在链接器设置中写入 -Wl,-R\\$$$$ORIGIN 以使其在构建日志中输出 -Wl,-R\\$ORIGIN 并正常工作。

【解决方案2】：

除了解决 Code:Blocks 问题的 kblucks 答案之外...... 对于像我这样偶然发现此页面并寻找如何使用 Make 进行此操作的人。诀窍是使用额外的 $ 符号作为转义字符并用引号将其括起来：

-Wl,-R,'$$ORIGIN/../lib'

完整的解释可以在这里： Using ORIGIN for a dynamic runtime library search path

【讨论】：

【解决方案3】：

如果您的可执行文件是由不是您创建的庞大复杂脚本环境构建的，并且您不想深入研究，请尝试使用setenv LD_RUN_PATH='$ORIGIN/../lib' 运行；如果这不起作用，实用的方法是为 ld 创建一个包装器：

#!/bin/sh
exec /usr/bin/ld -R '$ORIGIN/../lib' "$@"

... 然后在路径上使用该存根进行构建。在实践中，可能会调用它来构建 .so 文件或其他可执行文件，因此您可能需要将其设为更复杂的脚本，以决定是否插入 RPATH。或者，在没有这个的情况下运行构建，并使用樱桃挑选。

（这里“/usr/bin/ld”是通常会运行的 ld，可能在其他地方。gcc 可能无法从路径中获取 ld，请参阅 gcc 环境变量以覆盖它。里程可能会有所不同. 仅限一次性使用。不保证比任何其他方法都更糟糕）。

【讨论】：