GCC 链接顺序改变了？

Question

我正在尝试使用 GCC 链接一个 C++ 模块，基本上是这样的:

gcc -c hello.c
g++ -c world.cpp
gcc -ohello -lstdc++ hello.o world.o

请注意，我使用 -lstdc++链接 C++ 模块，以便我可以使用 gcc而不是 g++ .问题是我收到了错误:

undefined reference to `operator new(unsigned long)'

(假设 world.cpp 至少包含一个对 new 的调用。)

如果我输入 -lstdc++，则此错误已修复在链接器行的末尾，如下所示:

gcc -ohello hello.o world.o -lstdc++

我知道这个问题在这里被问过很多次，但我有一个特殊的要求。我没有直接调用 GCC。我正在使用代表我调用 GCC 的不同编程语言(Mercury)的构建系统，并且我无法轻松修改它调用 GCC 的方式(尽管我可以使用 LDFLAGS 环境变量指定其他库)。所以我有两个额外的要求:

我不能使用 g++链接(仅 gcc )——这就是我做 -lstdc++ 的原因上面的技巧，而不是简单地与 g++ 链接)。

我不认为我可以控制链接器命令的顺序——Mercury 会将 .o 文件放在任何库之后的命令行上。

我了解订单重要的基本原因，但令我困惑的是为什么现在中断了？我刚刚更新到 Ubuntu 11.10/GCC 4.6.1。多年来，我一直使用上述技术(将 -lstdc++ 放在首位)成功地编译了这个程序。直到现在才出现这个错误。我的一个不相关的程序使用 -lgl 链接到 OpenGL当我升级时这也坏了，我不得不搬家 -lgl到命令行的末尾。我可能会发现我的许多程序不再编译。为什么会发生这种变化？我的新系统有问题还是现在是这样？请注意，这些是普通的共享库，不是静态链接的。

我能做些什么来让 GCC 回到旧的方式，图书馆的顺序无关紧要吗？有没有其他方法可以说服 GCC 链接 libstdc++在 .o 之后不移动它命令行上的文件？

Answer 1

如果 Mercury 将目标文件放在库之后，Mercury 就会损坏。库属于目标文件之后 - 总是。您有时可能会以相反的顺序侥幸逃脱，但并不可靠。 (静态库必须跟踪引用静态库中符号的目标文件。有时，即使没有使用任何符号，链接器也会记录共享库定义的符号；有时，链接器只会记录共享库符号如果共享库提供至少一个符号。)