为什么指定输入库的顺序很重要?
我对 Linux 编程还很陌生。你可以说我是 Windows 人。因此,我将我的项目移植到 Linux,这几乎让我发疯:我确信我已经使用 -l 标志指定了所有依赖项,但我收到了“未解析的符号”错误。 然后我找到了这个主题,它解决了我的问题: Boost linking on Linux with GCC
有人可以解释一下为什么顺序很重要,以及它到底有多重要吗?我很确定 MSVC 链接器不是这种情况......
I'm quite new to programming for Linux. You could say I'm a Windows guy. So, I was porting my project to Linux, and it almost made me insane: I'm sure I have specified all the dependencies with -l flag, and yet I'm getting "unresolved symbol" errors.
Then I've found this topic, and it solved my problem: Boost linking on Linux with GCC
Could someone please explain me why does the order matter, and how exactly it matters? I'm pretty sure it is not the case with MSVC linker...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
一个简单的例子将让您了解为什么一次性 Unix 链接器关心顺序。
假设您有 main.o(由 main.cpp 生成)和库 libx.a(无依赖项)和 liby.a(依赖于名为 newRefX 的 libx)。
如果链接器按此顺序运行,则可以,因为链接器从 1 到 3:
但是如果链接器按照这个顺序,你会遇到问题newRefX:
因此,您可以看到您最后需要的是最低级别的库(不依赖于其他库的库)。
A simple example will let you see why one-pass Unix linkers care about order.
Suppose you have main.o (generated by main.cpp) and libraries libx.a (no dependencies) and liby.a ( depends on libx called newRefX).
If the linker goes in this order, you are fine as the linker goes from 1 to 3:
But if the linker goes in this order, you run into problems with newRefX:
So, you can see that you want the lowest level library (the one that depends on no others) last.
来自“GCC 简介 - 针对 GNU 编译器 gcc 和 g++”
我相信 msvc 链接器会对代码执行 2 次传递,因此即使以不同的顺序指定库(缺少引用...),它们也可能能够解析符号
From "An Introduction to GCC - for the GNU compilers gcc and g++"
I believe that msvc linkers do 2 passes over the code so they might be able to resolve the symbols even when the libraries are specified in different order (reference missing ...)
这就是 Unix 链接器的工作方式,从很久以前开始......请参阅 Levine 的书
It is the way the Unix linkers work, since long time ago... See Levine's book