logo标签列表

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

c++linuxgcc
11

我从源代码构建的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本身的安装路径吗？

这个手册并没有对我很有帮助：

1
有时需要在-Wl,-rpath之后加上-L。所以我想更广泛的问题是：在本地安装编译器后，如何让所有东西在这台机器上“正常工作”，忽略系统库/头文件？ - Aaron McDaid
你尝试过使用规格文件吗？ - fhossfel
https://dev59.com/sWQm5IYBdhLWcg3w8Sre#17224826提供了一种解决方案，用于在安装GCC后创建具有正确路径的规范文件。如果您稍后移动GCC安装，则需要重新创建规范文件。 - Jonathan Wakely
@JonathanWakely 感谢您提供的信息，但对于我来说这实际上是个坏消息，因为那个人和我都独立得出结论，规格文件必须根据每个安装进行调整（尽管这并不排除找到可移植解决方案的可能性）。 - nodakai
@nodakai 当你编译GCC时，可以在“configure”中指定“--with-specs”。你已经需要指定“--prefix”，所以这不应该更加困难。与此无关，我对你的规格字符串很好奇：为什么要修改“link_command”而不是只修改“link”？我还没有进行彻底的测试，但是通过我迄今为止所做的少量测试，似乎只需添加以下行即可完成工作：“*link: + %{!static:-rpath PREFIX/lib64 -enable-new-dtags}”，其中PREFIX是您传递给“--prefix”的任何内容。 - Daniel H
显示剩余2条评论
2个回答
4
当你编译GCC时，你需要传递你想要的前缀给configure。此时，你也可以使用--with-specs选项。根据我的实验，选项--with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}'(其中$prefix应替换为与--prefix相同的路径)是有效的(当然，你需要为多库支持做更复杂的设置)。

需要注意的事项:

  • 没有详细的文档说明，但是似乎与常规的spec files不同，--with-specs配置选项适用于传递给GCC本身的命令行参数。因此，您不能尝试修改*link规范字符串。
  • %x序列不会改变GCC命令行，而是累积要传递给链接器的参数。这就是为什么我直接传递-rpath和-enable-new-dtags而不是通过-Wl的原因。
  • 有很多关于要传递哪些规范的建议。我没有在任何地方看到这个，所以请谨慎对待。我使用自己的原因是所有其他人都修改了像*link这样的规范字符串，而您无法使用--with-specs，或者他们使用-Wl向GCC命令行添加选项，我相当确定有人说过他们遇到了麻烦，因为在某些情况下它会让GCC混淆，而他们并没有进行链接。你的情况可能不同。
  • 如果您使用引导（通常是除非构建交叉编译器，在这种情况下我可能是错误的，但我认为这种特定的rpath技巧无论如何都没有用），这将向GCC程序和共享库添加RUNPATH。这似乎是正确的选项，因为它们是针对现在位于$prefix/lib64中的库进行编译的，但值得注意。

  • 我添加了-enable-new-dtags，这将其放入DT_RUNPATH而不是DT_RPATH中。这是所有文档都说应该优先考虑的较新属性，<sarcasm>这就是为什么需要一个额外的标志，而文档中并没有明确交叉引用的原因</sarcasm>。 RPATH和RUNPATH之间的区别包括：

    • 如果存在RUNPATH，则完全忽略RPATH。
    • RPATH会覆盖LD_LIBRARY_PATH； RUNPATH不会。
    • 它们对依赖项的依赖项的工作方式略有不同（只有直接依赖项才会搜索RUNPATH；只要依赖链中没有任何内容具有RUNPATH，就会搜索RPATH）。更多细节请参见here。
    • 我想那就是全部，但如果我漏掉了什么，我也不会感到惊讶。

    正如我上面链接的文章所示，不是每个人都喜欢RUNPATH而不是RPATH，但在这里，除非您以复杂的方式混合来自不同编译器需要不同编译器支持库的代码，否则这不应该是一个问题，并且如果您这样做，我认为没有任何一种通用解决方案。

1
据我所知，GCC非常依赖于它编译的安装文件夹。我经常构建RTEMS交叉编译工具链，其中一个最重要的事情就是学习到，在生成的交叉编译器中有许多地方“烧录”了安装前缀（即传递给--exec-prefix的内容）。
“学习” - 意思是，我试图将编译器的文件夹移动到不同的路径，结果一切都乱了:-)
我的观点是：修改specs文件使其指向安装路径似乎在GCC看来是绝对正常的。
请查看musl-cross以获取反例。 - 0xC0000022L
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接