为什么静态和动态可链接库不同？

Question

如果它们都包含编译代码，为什么我们不能在运行时加载“静态”文件，为什么不能在编译时链接动态库？为什么需要单独的格式来包含“独立”代码？需要在其中任何一个中存储什么以保证差异？

Answer 1

静态库是真正的库，因为它们包含一个目标文件库。每个目标文件通常由单个源文件创建，并包含机器代码以及代码所需数据的相关信息。在链接步骤中，链接器将挑选必要的目标文件并将它们组合成一个可执行文件。

机器代码的一个重要部分是跳转、调用和数据指针必须包含真实的内存地址。但是，如果一个目标文件需要调用另一个目标文件中的另一个函数，它只能使用符号来引用该函数。当链接器将目标文件组合成可执行代码时，符号引用被解析并转化为实际内存地址。

动态库是可以加载到内存中并立即执行的可执行代码。在某些操作系统上，可能会有一个额外的步骤，即通过将可执行代码移动到另一个位置来重新定位代码，这需要将代码中的所有绝对地址移动一个固定的量。此操作仍然比链接器完成的组合目标文件和解析符号快得多。

总结一下：

• 静态库包含可执行代码片段，这些片段使用符号来引用其他可执行代码片段
• 动态库（和可执行文件）包含现在放置在固定位置的可执行代码，可以将符号替换为实际内存地址

如果您曾经尝试过链接一个规模合理的项目，您会注意到它花费的时间非常多，可能比您希望等待启动应用程序的时间还要长。这解释了为什么你不能执行静态库。动态库已经过优化和剥离，除了可执行代码之外不包含任何内容，这使得它们不适合用作静态库。

Answer 2

目标文件中的代码未链接。它包含对尚未解析的外部函数的隐式引用。

当链接目标文件以创建 DLL 时，链接器会查看所有这些外部引用并找到可以满足它们的其他库（静态或动态）。通过将该函数（或其他）的主体包含到 DLL 中来解析对静态库中名称的引用。如果引用动态库，则DLL的名称和引用的函数都包含在DLL中。

最终，没有理由必须会是这种情况。理论上，您可以编写加载程序来在每次加载文件时执行所有这些操作。它基本上只是一种优化：链接器完成工作中相对较慢的部分。对 DLL 的引用被保留了，但是它们被解析到加载器找到并加载目标文件（如果需要）并解析引用的函数的速度相当快。当链接器完成它的工作时，它会通过扫描长长的定义列表来查找您关心的定义，这会慢很多。

Answer 3

注意：以下答案不是平台无关，而是特定于基于 ELF 的系统和其他一些类似的系统。其他人可以填写其他系统的详细信息。

什么是静态库？

静态库是存档中*.o 文件的集合。每个文件都可以包含对必须由链接器解析的未定义符号的引用，例如，您的库可能有对printf 的引用。该库没有提供任何关于在何处找到 printf 的指示，预计链接器会在它被要求链接的其他库之一中找到它。

假设您的库包含以下代码：

read_png.o
write_png.o
read_jpg.o
write_jpg.o
resize_image.o
handle_error.o

如果应用程序仅使用read_png 和write_png，则其他代码段将不会加载到可执行文件中（handle_error 除外，它是从read_png 和write_png 调用的）。

我们无法在运行时加载静态库，因为：

• 链接器不知道在哪里可以找到外部对象，例如，printf。

• 会很慢。动态库针对快速加载进行了优化。

• 静态库没有命名空间的概念。我无法定义自己的handle_error，因为它会与库的定义冲突。

什么是动态库？​​

在 ELF 系统上，动态库与可执行文件是同一类型的对象。它还导出更多符号，一个可执行文件只需要导出_start。动态库经过优化，因此可以将整个内容直接映射到内存中。

如果您在动态库中调用了printf，除了静态库的要求之外，还有一些额外的要求：

• 你必须指定哪个库有printf。

• 您必须以特殊方式调用该函数，让链接器插入printf 的地址。在静态库中，链接器可以直接修改您的代码并插入地址，但对于共享库，这是不可能的。

我们不想使用动态库来静态链接，因为：

• 我们不能只链接动态库的一部分。即使我们的可执行文件从不调用read_jpg，它也会被包含在内，因为动态库是全有或全无。

• 函数调用的额外开销是浪费的，即使它很小。

总结

编译看起来像这样：

Source  ==compile==>  Object  ==link==>  Executable / Shared Library

静态库是一个包含尚未链接的对象的档案。还有很多工作要做。

共享库是链接的最终产品，可以加载到内存中。

首先发明了静态库。如果两者是同时发明的，它们可能会更加相似。

Answer 4

没有根本原因您不能将静态库 (.a) 文件用作动态库，在程序启动时甚至在运行时动态加载和链接它们。但是，它们没有经过专门编译并准备在任意地址运行内存映射（甚至对齐也不一定正确！），因此加载程序代码必须分配内存，从.a文件中读取必要的对象进入此内存，并对其进行重大修改。当然，这些记忆都不是可共享的。因此，这可能是一个非常糟糕的主意...

Answer 5

静态库 == tarball 而动态 == 部分链接的连续图像

静态库只是.o or.obj` 文件的压缩包¹。当一个可执行文件被链接时，引用的模块（以及它们引用的模块，然后是它们引用的模块，然后......等等）将从静态库中复制出来并附加到主程序的末尾。整个事情作为单个操作系统“对象”被分页到内存中。

动态库只是获取静态库的所有元素，将它们链接在一起（解决内部关系），然后将整个内容映射到内存中。 （按需分页可能会导致部分内存存在。）在启动动态程序时，为了将主程序（将在其自己的模块中“静态”链接）连接到共享的库，需要进行一定量的摆弄全系统。有时这种摆弄会延迟每个链接元素，直到进行给定的调用。在一个非常宽泛的、过度概念化的扫描中，可以将静态链接归类为急切加载，将动态链接归为延迟加载。

静态库有利有弊。

✚ 没有 DLL 地狱（又名 依赖地狱）
✚运行时进程混合
- 不同程序的大型运行时进程混合需要更大的内存占用
- 不能在它们之间共享任何库代码内存进程，除非它们运行相同的程序
-大量程序（如 Linux/Windows/Mac 足迹）占用大量空间，因为 printf et al 在每张图像中一遍又一遍地重复
- 修复源自库的安全漏洞即使不是不可能也很困难
- 更新即使不是不可能也很困难单独一个库
✚ 单独更新一个库并破坏您的程序是很困难的，如果不是不可能的话

---

^{1.实际上，它们不是 tar(1) 格式，但它是相关的。}

Answer 6

区别在于：

• 静态库并编译和链接
• 动态库已链接

参考文献

• Avoiding LD_LIBRARY_PATH
• Shared Libraries HOWTO