我没有给每次从源代码构建的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本身的安装路径？
本手册页对我帮助不大：
据我所知，GCC非常依赖于它编译的安装文件夹。我经常构建RTEMS交叉编译工具链，我学到的第一件事就是生成的交叉编译器中有很多地方安装前缀（即传递给--exec-prefix的任何内容）被“烧掉”。
“学到了” - 就像在，我试图将编译器的文件夹移动到另一条路径，并且所有地狱都破裂了:-)
我的观点：就GCC而言，修改specs文件以使它们指向安装中的路径似乎绝对正常。
在编译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 - 前缀`）可以工作（当然，你需要一些更复杂的for multilib支持）。
注意事项：
--with-specs配置选项适用于传递给GCC本身的命令行参数。因此，您不能只是尝试修改*link规范字符串。%x序列不会更改GCC命令行，但会累积参数以传递给链接器。这就是为什么我直接通过-rpath和-enable-new-dtags而不是通过-Wl。*link这样的规范字符串，你无法用--with-specs做，或者他们使用-Wl为GCC命令行添加选项，我相当有人说他们遇到了麻烦因为在某些情况下，当他们没有链接时，它会混淆GCC。因人而异。RUNPATH同样。这似乎是正确的选择，因为它们是针对现在在$prefix/lib64中的库编译的，但值得注意。-enable-new-dtags，它把它放在DT_RUNPATH而不是DT_RPATH。这是所有文档中应该首选的新属性，
这就是为什么它需要一个额外的标志，在文档中没有明确的交叉引用
。 RPATH和RUNPATH之间的区别在于：
如果存在RUNPATH，则将完全忽略RPATH。
RPATH优先于LD_LIBRARY_PATH; RUNPATH没有。
它们对依赖关系的依赖性有所不同（RUNPATH只搜索直接依赖关系;只要依赖关系链中没有任何东西有RPATH，就会搜索RUNPATH的间接依赖关系）。更多细节可用here。
我认为这就是一切，但如果我遗失了什么，我不会感到惊讶。
正如我在上面链接的文章所指出的那样，并不是每个人都喜欢RUNPATH到RPATH，但是这里不应该是一个问题，除非你以复杂的方式混合需要不同编译器支持库的不同编译器的代码，如果你这样做，我不会认为有任何一刀切的解决方案。