linux - 在编译时链接共享对象

Question

在 Windows 中，许多 .dll 都带有对应的静态 .lib。我的理解是 .lib 副本基本上包含 LoadProcAddress 调用，这样程序员就不必自己动手了。本质上，节省时间。当我切换到 Linux 时，我假设情况是一样的，将 .dll 替换为 .so，将 .lib 替换为 .a，但我遇到的情况表明这是错误的，我无法弄清楚是什么进行中:

我正在使用一个以 .a/.so 对形式出现的库。我正在链接 .a，但是当我在生成的二进制文件上执行 ldd 时，它不包含对相应 .so 文件的引用。然后，我尝试链接到 .so 文件，令我惊讶的是，这有效。此外，当我对生成的二进制文件执行 ldd 时，.so 文件出现了。

所以，我真的很困惑到底发生了什么。在 Windows 中，我绝不会想到链接到 .dll 文件。此外，在 Windows 中，如果 .dll 文件附带 .lib 并且我在编译时链接到 .lib，那么我希望在运行时依赖于相应的 .dll。在这种情况下，这两件事都不是真的。

是的，我已经阅读了 Linux 中有关共享对象的基础教程，但我所阅读的一切似乎都表明我最初的假设是正确的。顺便说一句，我应该提到我正在使用 Code::Blocks 作为 IDE，我知道这会使事情复杂化，但我 99% 确定当我告诉它链接到 .so 文件时，它不仅仅是换出.a 文件，因为生成的二进制文件较小。 (加上关于 ldd 的整个业务......)

无论如何，先谢谢了。

Answer 1

I was linking against the .a, but when I executed ldd on the binary that was produced, it contained no reference to the corresponding .so file.

这是预料之中的。当您静态链接时，静态库的代码会集成到生成的二进制文件中。不再有对静态库的引用或依赖。

So then, I tried linking against the .so file and to my surprise, this worked.

静态链接不起作用是什么意思？没有理由不应该...