GCC规范文件：如何获取安装路径答案

【问题标题】：GCC specs file: how to get the installation pathGCC规范文件：如何获取安装路径
【发布时间】：2015-12-02 12:33:06
【问题描述】：

我没有将-Wl,-rpath=$HOME/local/gcc52/lib64 分配给我从源代码构建的每次调用GCC 5.2，而是以这种方式修改了它的spec 文件：

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) -rpath=%:getenv(HOME /local/gcc52/lib64) ...

但这取决于我在$HOME/local/gcc52 下的具体安装。有没有更好的方法来引用被调用的GCC本身的安装路径？

这个手册页对我帮助不大：

https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

【问题讨论】：

有时需要-L 和-Wl,-rpath。所以我想更广泛的问题是：在本地安装编译器之后，我们如何让所有东西在这台机器上“正常工作”，忽略系统库/头文件？
您是否尝试过使用规格文件？
stackoverflow.com/a/17224826 提供了一种在安装 GCC 后创建具有正确路径的规范文件的解决方案。如果您稍后移动 GCC 安装，则需要重新创建规范文件。
@JonathanWakely 感谢您提供信息，但这对我来说实际上是个坏消息，因为我和那个人都独立得出结论，每次安装都必须调整规范文件（尽管这不会消除找到便携式解决方案的可能性。）
@nodakai 在编译 GCC 时，可以指定 --with-specs 到 configure。您已经需要指定--prefix，所以这应该不会再困难了。与此无关，我很好奇你的规范字符串：你为什么要修改link_command 而不仅仅是link？我还没有对它进行彻底的测试，但是到目前为止我已经做了少量的测试，看起来只要添加行*link: + %{!static:-rpath PREFIX/lib64 -enable-new-dtags}，其中PREFIX 是你传递给--prefix 的任何东西，就可以完成这项工作。跨度>

标签： c++ linux gcc

【解决方案1】：

当你编译 GCC 时，无论如何你都需要将你想要的前缀传递给 configure。到时候也可以给它--with-specs选项。根据我的实验，--with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' 选项（$prefix should be replaced by the same path you pass to--prefix`）可以工作（当然，你需要更复杂的东西来支持多库）。

注意事项：

这在任何地方都没有正确记录，但似乎与常规 spec files 不同，--with-specs 配置选项适用于传递给 GCC 本身的命令行参数。因此，您不能只尝试修改 *link 规范字符串。
%x 序列不会更改 GCC 命令行，但会累积参数以传递给链接器。这就是为什么我直接通过-rpath 和-enable-new-dtags 而不是通过-Wl。
网上有很多关于通过什么规范的建议。我在任何地方都没有看到这个，所以它带着一粒盐。我使用自己的原因是所有其他人要么修改像*link 这样的规范字符串，而--with-specs 无法做到这一点，或者他们使用-Wl 向GCC 命令行添加选项，我相当确定有人说他们遇到了麻烦，因为在某些情况下，当他们没有链接时它会混淆 GCC。 YMMV。
如果您使用引导程序（除非构建交叉编译器，否则您通常会这样做，在这种情况下我可能是错的，但我认为这个特殊的 rpath 技巧无论如何都没有用），这将添加一个 RUNPATH 到GCC 程序和共享库也是如此。这似乎是正确的选择，因为它们是针对现在位于 $prefix/lib64 中的库编译的，但值得注意。
我添加了-enable-new-dtags，这会将其放入DT_RUNPATH 而不是DT_RPATH。这是所有文档都说应该首选的较新属性，这就是为什么它需要一个额外的标志，而该标志在文档中没有明确交叉引用。 RPATH 和 RUNPATH 之间的区别包括：
- 如果存在 RUNPATH，RPATH 将被完全忽略。
- RPATH 覆盖LD_LIBRARY_PATH； RUNPATH 没有。
- 它们对依赖项的依赖项的工作方式有所不同（RUNPATH 仅搜索直接依赖项；RPATH 搜索间接依赖项，只要依赖项链中没有RUNPATH）。更多详细信息，请访问here。
- 我认为这就是一切，但如果我遗漏了什么，我不会感到惊讶。
正如我上面链接的文章所示，并不是每个人都更喜欢 RUNPATH 而不是 RPATH，但在这里它应该不是问题，除非你以复杂的方式混合来自不同编译器的代码，需要不同的编译器支持库，如果你这样做我不要认为有任何一刀切的解决方案。

【讨论】：

【解决方案2】：

据我所知，GCC 非常依赖于编译它的安装文件夹。我非常频繁地构建 RTEMS 交叉编译工具链，我学到的第一件事是在生成的交叉编译器中有许多位置安装前缀（即传递给 --exec-prefix 的任何内容） ) 被“烧掉”了。

“Learned” - 例如，我试图将编译器的文件夹移动到不同的路径，但一切都崩溃了 :-)

我的观点：就 GCC 而言，修改 specs 文件以使其指向安装中的路径似乎是绝对正常的。

【讨论】：

查看 musl-cross 的反例。