GCC规格文件:如何获取安装路径 [英] GCC specs file: how to get the installation path

问题描述

我没有为从源代码构建的GCC 5.2的每次调用提供-Wl,-rpath=$HOME/local/gcc52/lib64，而是通过以下方式修改了其spec文件:

Instead of giving -Wl,-rpath=$HOME/local/gcc52/lib64 to each invocation of GCC 5.2 which I built from the source, I modified its spec file in this way:

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

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

But this depends on my specific installation under $HOME/local/gcc52. Are there better way to refer to the installation path of the invoked GCC itself?

该手册页对我没有太大帮助:

This manual page did not help me much:

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

推荐答案

在编译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`)有效(当然，需要更多复杂的支持Multilib).

When you’re compiling GCC, you need to pass the prefix you want to configure anyway. At that time, you can also give it the --with-specs option. Based on my experiments, the option --with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' (where $prefix should be replaced by the same path you pass to--prefix`) works (you need something more complicated for multilib support, of course).

注意事项:

• 此文件在任何地方都没有正确记录，但看起来与常规 spec文件，--with-specs configure选项适用于传递给GCC本身的命令行参数.因此，您不能只是尝试修改*link规范字符串.
• %x序列不会更改GCC命令行，但会累积参数以传递给链接器.这就是为什么我直接通过-rpath和-enable-new-dtags而不是通过-Wl的原因.
• 在线上有大量关于要通过哪些规格的建议.我在任何地方都没有看到这个，所以它带着一粒盐.我使用我自己的原因是所有其他人要么修改了*link之类的规范字符串，而您不能使用--with-specs做这些字符串，要么他们使用-Wl向GCC命令行中添加了选项，我敢肯定有人说他们遇到了麻烦，因为在某些情况下，当他们不连接时，它会混淆GCC. YMMV.
• 如果您使用引导程序(除非构建交叉编译器，否则通常使用引导程序，在这种情况下我可能会错了，但我认为这个特殊的rpath技巧仍然无济于事)，这将在GCC程序和共享库也是如此.这似乎是正确的选择，因为它们是针对现在$prefix/lib64中的库进行编译的，但是值得注意.

• 我添加了-enable-new-dtags，将其放置在DT_RUNPATH中，而不是在DT_RPATH中.这是所有文档都应首选的较新属性，即< sarcasm> ;，这就是为什么它需要一个额外的标记的原因，该标记在docs//sarcasm>中没有明确交叉引用. RPATH和RUNPATH之间的区别包括:

• This isn’t properly documented anywhere, but it appears that, unlike with regular spec files, the --with-specs configure option applies to the command-line arguments passed to GCC itself. Thus, you can’t just try to modify the *link spec string.
• The %x sequence doesn’t change the GCC command line, but accumulates arguments to pass to the linker. That’s why I pass -rpath and -enable-new-dtags directly instead of via -Wl.
• There are a bunch of suggestions online for what specs to pass. I didn’t see this one anywhere, so it take it with a grain of salt. The reason I used my own is that all the others either modify a spec string like *link, which you cannot do with --with-specs, or they add options to the GCC command line using -Wl, which I’m fairly sure somebody said they had trouble with because in some cases it confused GCC when they weren’t linking. YMMV.
• If you use bootstrapping (which you usually are unless building a cross-compiler, in which case I could be wrong but I don’t think this particular rpath trick is useful anyway), this will add a RUNPATH to the GCC programs and shared libraries as well. This seems to be the correct option, because they were compiled against the libraries that are now in $prefix/lib64, but it’s worth noting.

• I added -enable-new-dtags, which puts this in DT_RUNPATH instead of DT_RPATH. This is the newer attribute which all the documentation says should be preferred, <sarcasm>which is why it requires an extra flag which isn’t clearly cross-referenced in the docs</sarcasm>. Among the differences between RPATH and RUNPATH are:

• 如果存在RUNPATH，则将完全忽略RPATH.
• RPATH覆盖LD_LIBRARY_PATH； RUNPATH不会.
• 对于依赖项的依赖关系，它们的工作有所不同(仅在依赖项链中没有RUNPATH的情况下，RUNPATH仅搜索直接依赖项；对于间接依赖项，RPATH进行搜索). 此处.
>
• 我认为这就是一切，但是如果我缺少某些东西，我也不会感到惊讶.

• If RUNPATH is present, RPATH will be completely ignored.
• The RPATH overrides LD_LIBRARY_PATH; the RUNPATH does not.
• They work somewhat differently for dependencies of dependencies (RUNPATH is only searched for direct dependencies; RPATH is searched for indirect dependencies as long as nothing in the dependency chain has a RUNPATH). More details are available here.
• I think that’s everything, but I wouldn’t be surprised if I’m missing something.

正如我在上面链接的文章所指出的那样，并不是每个人都更喜欢RUNPATH而不是RPATH，但在这里这不是问题，除非您以复杂的方式混合了来自需要不同编译器支持库的不同编译器的代码，如果您这样做，不要以为有一种万能的解决方案.

As the article I linked above indicates, not everybody prefers RUNPATH to RPATH, but here it shouldn’t be an issue unless you mix code from different compilers requiring different compiler support libraries in a complicated way, and if you do that I don’t think there’s any one-size-fits-all solution.

这篇关于GCC规格文件:如何获取安装路径的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！