静态库与动态库中的符号解析
有一个免费软件项目可以构建一些静态 C++ 库，然后 将它们链接起来以生成二进制文件。我想将库分开 .so 文件用于动态链接（因此其他项目可能会使用 库）。一个库构建得很好，但是当我尝试链接时 它，我收到“未定义的参考”错误。
这些很容易追踪和修复（代码引用了那些 .h 文件中的方法，但相应的 .cc 文件不是 包含在 Makefile 编译命令中）。然而我却是 想知道为什么，一般来说，图书馆会链接 作为静态库很好，但作为动态库则不行。什么是 g++ 和 ld 在一种情况下执行，但在另一种情况下则不执行？
非常感谢。
There is a free software project that builds some static c++ libs and then
links them to make a binary. I'd like to separate the libraries out as
.so files for dynamic linking (so other projects might make use of
the lib). One library builds just fine, but when I try to link
it, I get "undefined reference" errors.
Those are easy to track down and fix (the code referenced those
methods in a .h file but the corresponding .cc file was not
included in the Makefile compile command). I am, however,
wondering why, as a general matter, a library would link just
fine as a static library but not as a dynamic library. What are
g++ and ld doing in one case but not the other?
Thanks much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 ar 创建的静态库只是一堆目标文件。 ar 是一个非常简单的存档器。链接时没有解析任何依赖项，请参阅 ar 的手册页。
另一方面，共享对象，或者您所说的动态库，是一种非常不同的野兽。它们实现了 ELF 二进制格式并具有复杂的规则集。它们还有初始化代码，并且一些依赖项在链接时得到解决。请参阅 http://www.akkadia.org/drepper/dsohowto.pdf 和 http://www.akkadia.org/drepper/goodpractice.pdf 进行更深入的介绍。
static libraries, created with ar are just a bunch of object files. ar is a very simple archiver. There are no dependencies resolved at link time, see the man page of ar.
Shared objects on the other hand, or dynamic libraries as you call them are a very different beast. They implement the ELF binary format and have a complicated ruleset. They also have initializing code, and some dependencies are resolved at link time. See http://www.akkadia.org/drepper/dsohowto.pdf and http://www.akkadia.org/drepper/goodpractice.pdf for a deeper introduction.
向我们展示您的链接命令。链接共享库时，通常不会出现“未定义引用”错误，因为共享库允许（默认情况下）具有未解析的符号。
或者您的意思是，当您将最终的可执行文件链接到共享库时，会出现“未定义的引用”错误？
Show us your link command. "Undefined reference" errors are generally not expected when linking a shared library, because shared libraries are allowed (by default) to have unresolved symbols.
Or did you mean that you get "undefined reference" errors when you link the final executable against the shared library?