c++ - 关于 Linux c++ 静态库

Question

这里我有几个关于静态库的问题需要你的帮助。

我从一些书上了解到，一个静态库(Linux中的.a)包含一组编译对象，当它链接成一个可执行文件时，链接工具只会取出那些实际引用的对象。

因此，如果 .a 包含 1.o、2.o 和 3.o，而我的应用程序仅使用 1.o 中的函数，那么只有 1.o 将被构建到可执行文件中，这是否正确？

然后让我们更进一步，假设我们有 2 个 .a 库，第一个包含 1.o、2.o 和 3.o，第二个包含 3.o 4.o 和 5.o。如果我的应用程序只使用 1.o 2.o 3.o 和 4.o 中的函数，那么只有这 4 .o 将被构建到可执行文件中，是否正确？

我提出这个问题是因为我正在构建一些与 MSVC 一起使用的 .a 文件。这些 .a 库是在 MinGW 中构建的，因此应该与 MSVC 兼容。我可以将这些库包含到 MSVC 项目中并成功构建我的程序。但是生成的可执行文件是 5 MB(所有 .a 的总大小应该约为 8MB)，即使我的程序是一个空程序(只有一个空的主函数)也是如此。

这是否意味着，当 .a 在 MSVC 或 .lib(Win 的静态库)中使用时，将作为一个整体构建到可执行文件中，而不是它在 Linux 下的行为方式？

还有我对以下内容有疑问

如果我可以使用 -static 链接到静态版本的 lib tiff，那么为什么它需要链接到其他库？静态库是否应该已经包含它需要的所有代码？

谢谢

Answer 1

静态库不会包含它需要的所有代码。想象一个使用 printf() 输出错误信息的库。这个库仍然依赖于 libc 的静态版本，它不会包含 printf 本身的代码。

在您的情况下，由于 Tiff 支持各种内部表示格式，其中一种是 jpeg，因此静态 libtiff 希望您链接静态 libjpeg。

windows和linux在这一点上没有本质区别。当您对 libtiff 和 libjpeg 进行静态链接时，只会链接 libtiff 实际需要的 libjpeg 函数，而不是例如处理 JFIF Jpeg 包装器的部分。

编辑 - 回复评论

在您的 main() 被调用之前有很多事情要做。在 linux/unix 上并没有那么多，操作系统以 main() 想要的方式传递参数，但在 Windows 上，一个不同的函数，通常称为 WinMain() 获取控制程序何时启动。此 WinMain() 隐藏在库中。它在一个字符串中获取整个命令行，并且必须解析参数以将它们传递给 main()，这意味着检查空格，这可能是使用 isspace() 实现的，它会引入 ctype，它会引入很多与语言环境相关的东西，等等。您的 5 MB 中的大部分可能是用于使您的程序在 Windows 中像在 Unix 中一样工作的代码。此外，如果您在启用调试选项的情况下进行编译，这些调试符号也会占用大量空间。

Keltar 关于调用动态库的静态库的评论也是正确的——但这增加了您并不经常需要的复杂性。静态链接或多或少有两个原因:

• 您希望您的程序即使在动态库出现问题时也能运行。如果我不小心 rm/lib/libc.so.* 如果我有 mount 和 cp 的静态链接版本来复制它，我会很高兴从别的地方。因此，安装程序和“紧急程序”通常是静态链接的
• 您要确保您的程序使用特定版本的库，该版本在您编译时在您的系统上是最新的，而不是 5 年后某些系统上可能安装的 dynalink 版本。

如果一些但不是所有库是静态的，那么这两个原因都没有多大意义。

不过也有异常(exception):假设您需要 libtiff 中的特定功能。您浏览了文档，但它只字未提该功能。您检查源代码并发现它实现了 specific_feature()，并带有一个很大的注释“这是实验性的，可能会在未来的版本中消失”。如果您决定现在需要该功能，您可能希望静态链接 libtiff 以防止您的程序在未来版本的 libtiff 不再实现该功能时失败。当然，您仍然需要 libjpeg 和 libc 的动态版本。如果这对您来说是个好习惯，我会让您做决定。

Windows 是一个特例，因为它始终使用 kernel.dll 和 user32.dll，因为它们 没有静态版本，即使程序的其余部分是静态链接的也是如此。

因此，虽然 libtiff.a 可能 需要 libjpeg.so，而 libtiff.lib 可能 需要 libjpeg.dll，但通常没有太多理由这样做.