解码gcc规范文件行

Question

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

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

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

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

而且出现影响LIBRARY_PATH的设置/修改，我黯然不知道什么这行的意思。 因此，我希望你们中的一些人能够“解密”这一行并解释它的含义，以便我可以根据我的要求尝试修改它。

谢谢！

Answer 1

这条线影响库如何相对于GCC的$PREFIX/lib目录中找到

有三个部分，它（其中$PREFIX是目录GCC安装到。）：

$PREFIX/lib/.使用时既不-m32或在命令行上使用-m64。

$PREFIX/lib/.:$PREFIX/lib/../lib64当使用-m64时被使用。

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

这向我建议你使用的是Debian或Ubuntu，我不认为从FSF源文件构建的vanilla GCC会在规范中使用。您的GCC版本是.deb套件还是您自己安装的？ （在最近的Debian/Ubuntu的多足弓支撑释放移动库目录等破坏香草GCC，我认为Debian和Ubuntu补丁的GCC代码为他们.deb包。）

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

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