Question

我没有给每次从源代码构建的GCC 5.2调用-Wl,-rpath=$HOME/local/gcc52/lib64，而是以这种方式修改了它的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

Answer 1

据我所知，GCC非常依赖于它编译的安装文件夹。我经常构建RTEMS交叉编译工具链，我学到的第一件事就是在生成的交叉编译器中有多个位置，其中安装前缀（即传递给{{1的任何内容）被烧伤＆＃34;烧伤＆＃34;英寸

＆＃34;教训＆＃34; - 就像在，我试图将编译器的文件夹移动到另一条路径，并且一切都崩溃了： - ）

我的观点：就GCC而言，修改--exec-prefix文件使它们指向安装中的路径似乎绝对正常。

Answer 2

当您编译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 - 前缀`）可以工作（当然，您需要更复杂的多点支持）。

注意事项：

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

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

2 个答案: