解码gcc规格文件行 [英] Decoding gcc specs file line

问题描述

我在两个版本（ g ++ -v 给出这个信息）之间对g ++的隐式LIBRARY_PATH修改有问题。我将LIBRARY_PATH设置为具有自定义库的单个本地目录。然而，事实证明，只有一个版本的g ++（让我们称之为版本A）正确链接，另一个（版本B）链接到系统默认的，这是不希望的。显然，目录的顺序混淆了，我的规范没有得到适当的尊重。这与 LIBRARY_PATH不再用于/ usr / lib之前的问题类似在gcc 4.2及更高版本中？，尽管不适用于这些版本。

不知何故，我想出了两个不同版本的规格文件（通过 g ++ -dumpspecs>规格获得）。然后我试着看看用另一个版本（A）的规格文件运行g ++版本（B;这是产生* un *期望的修改）是否仍然会产生这种修改，对我来说，LIBRARY_PATH现在完全与我预计它（匹配版本A）！

我进一步追溯了这个奇怪修改的地方，发生在下面一行：

 。 ！m64！m32;。：../ lib64 m64！m32;。：../ lib32！m64 m32; 
  

除了显示会影响LIBRARY_PATH的设置/修改外，我很遗憾不知道这行代表什么意思。
因此，我希望你们中的一些人能够解密这一行并解释它的含义，以便我可以根据我的要求尝试修改它。

感谢您！

解决方案

该行影响如何找到相对于GCC的库 $ PREFIX / lib 目录（其中 $ PREFIX 是GCC安装目录。）

有三个部分：

$ PREFIX / lib /.用于 -m32 或 -m64 用于命令行。

$ PREFIX / lib /.:$当使用 -m64 时，使用PREFIX / lib /../ lib64 p>

$ PREFIX / lib /.:$当 > -m32 被使用。

这表明你使用的是Debian或Ubuntu，我不认为从FSF的消息来源将在规格中。你们的GCC版本是不是来自 .deb 软件包，还是你自己安装的？ （最近Debian / Ubuntu发行版中的Multi Arch支持会移动库目录，所以会破坏vanilla GCC，我认为Debian和Ubuntu会为它们的 .deb 包修补GCC代码。）

您可以为每个版本添加链接的输出结果 g ++ -v ，以查看确切的库搜索每个版本使用的路径？

另外，为什么不使用 -L 而不是 LIBRARY_PATH ？在系统目录或GCC自己的目录或 LIBRARY_PATH 中指定的目录之前，以 -L 指定的目录总是排在第一位。

I have a problem with the implicit LIBRARY_PATH modification of g++ between two versions (g++ -v gives this info). I set the LIBRARY_PATH to a single local directory where I have custom libraries. However, it turned out that only one version of the g++ (let's call it version A) correctly linked, the other (version B) linked to the system-default, which was not desired. Apparently, the order of directories was mixed up and my specification was not properly respected. It is a similar issue to LIBRARY_PATH not used before /usr/lib anymore in gcc 4.2 and later? although not with these versions.

Somehow I came along the idea to have a look at the specs files of the two different versions (got them via g++ -dumpspecs > specs). I then tried to see if running the version of g++ (B; that was producing the *un*expected modifications) with the specs file of the other version (A) would still yield that modification and to my relief the LIBRARY_PATH was now exactly as I expected it (matching version A)!

I further traced down the place of this weird modification to happen at the following line:

. !m64 !m32;.:../lib64 m64 !m32;.:../lib32 !m64 m32;

Besides appearing to affect the setting/modification of LIBRARY_PATH, I sadly have no clue what this line means. Therefore I hope that some of you is able to "decipher" this line and explain what it means so that I can try to modify it according to my requirements.

Thank you!

解决方案

That line affects how libraries are found relative to GCC's $PREFIX/lib directory (where $PREFIX is the directory GCC was installed to.)

There are three parts to it:

$PREFIX/lib/. is used when neither -m32 or -m64 is used on the command-line.

$PREFIX/lib/.:$PREFIX/lib/../lib64 is used when -m64 is used.

$PREFIX/lib/.:$PREFIX/lib/../lib32 is used when -m32 is used.

This suggests to me you are using Debian or Ubuntu, I don't think a vanilla GCC build from the FSF sources would have that in the specs. Were both your GCC versions from .deb packages or did you install them yourself? (The Multi Arch support in recent Debian/Ubuntu releases moves library directories and so breaks vanilla GCC, I think Debian and Ubuntu patch the GCC code for their .deb packages.)

Could you add the output of linking with g++ -v for each of your versions, to see the exact library search paths used by each version?

Also, why not just use -L instead of LIBRARY_PATH? Directories specified with -L always come first, before the system dirs or GCC's own dirs or the ones specified in LIBRARY_PATH.

这篇关于解码gcc规格文件行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！