如果它们都包含已编译的代码，为什么我们不能在运行时加载“静态”文件，为什么我们不能在编译时链接动态库？为什么需要单独的格式来包含“独立”代码？什么需要存储哪个保证差异？
答案 0 :(得分：21)
静态库是真正的库，因为它们包含目标文件库。每个目标文件通常是从单个源文件创建的，包含机器代码以及有关代码所需数据的信息。在链接步骤中，链接器将选择必要的目标文件并将它们组合成可执行文件。
机器代码的一个重要部分是跳转，调用和数据指针必须包含实际的内存地址。但是，如果目标文件需要调用另一个目标文件中的另一个函数，则它只能使用符号引用该函数。当链接器将目标文件组合成可执行代码时，符号引用将被解析并转换为实际内存地址。
动态库是可执行代码，可以加载到内存中并立即执行。在某些操作系统上，可能存在另外的步骤，其中通过将可执行代码移动到另一个位置来重新设置代码，并且这要求代码内的所有绝对地址被移位固定量。此操作仍然比组合目标文件和解析链接器完成的符号要快得多。
总结一下：
如果您曾试图链接一个合理大小的项目，您会注意到它需要花费非常少的时间，可能比您希望等待启动应用程序的时间长。这就解释了为什么你不能执行静态库。动态库已经过优化和剥离，除了可执行代码之外不包含任何内容，这使得它们不适合用作静态库。
答案 1 :(得分：6)
目标文件中的代码未链接。它包含对尚未解析的外部函数的隐式引用。
当链接目标文件以创建DLL时，链接器会查看所有这些外部引用，并查找可满足它们的其他库（静态或动态）。通过将该函数的主体（或其他）包含到DLL中来解析对静态库中的名称的引用。如果它引用动态库，则DLL和引用函数的名称都包含在DLL中。
最终，没有理由认为 就是这种情况。从理论上讲，每次加载文件时都可以编写加载程序来完成所有这些操作。它基本上只是一个优化：链接器执行相对较慢的工作部分。剩下对DLL的引用，但它们被解决到加载器查找和加载目标文件（如果需要）并解析引用的函数相当快的程度。当链接器正在完成它的工作时，它会通过扫描很长的定义列表来找到你关心的那些，这会慢很多。
答案 2 :(得分：4)
注意：以下答案是不平台不可知，但特定于基于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从{{1}调用}和write_png）。
我们无法在运行时加载静态库，因为：
链接器不知道在哪里可以找到外部对象，例如printf。
这会很慢。动态库经过优化，可以快速加载。
静态库没有命名空间的概念。我无法定义自己的handle_error，因为它会与图书馆的定义冲突。
什么是动态库？
ELF系统上的动态库与可执行文件是同一类型的对象。它还会导出更多符号，可执行文件只需要导出_start。动态库经过优化，因此整个事物可以直接映射到内存中。
如果您在动态库中调用printf，则除了静态库的要求之外还有一些其他要求：
您必须指定哪个库具有printf。
您必须以特殊方式调用该函数，以便链接器插入printf的地址。在静态库中，链接器只需修改代码并直接插入地址，但共享库无法实现这一点。
我们不想使用动态库进行静态链接，因为：
我们无法仅链接动态库的一部分。即使我们的可执行文件从不调用read_jpg，它也会被包含在内，因为动态库是全有或全无的。
函数调用的额外开销是浪费，即使它很小。
<强>摘要
编译看起来像这样：
Source ==compile==> Object ==link==> Executable / Shared Library
静态库是一个存档，其中包含尚未链接的对象。还有很多工作要做。
共享库是一个链接的最终产品，可以加载到内存中。
首先发明了静态库。如果两者都是同时发明的，那么它们可能会更加相似。
答案 3 :(得分：3)
没有根本原因你不能将静态库（.a）文件用作动态库，在程序启动时加载和链接它们，甚至在运行时动态加载它们。但是，它们没有经过特殊编译和准备在任意地址运行内存映射（甚至对齐也不一定正确！），因此加载器代码必须分配内存，从{{1}读取必要的对象将文件放入此内存，并对其执行重大修改。当然，这些记忆都不可分享。因此，这可能是一个非常糟糕的主意......
答案 4 :(得分：1)
静态库只是.o or。obj`文件的tarball 1 。当可执行文件被链接时，引用的模块（以及它们引用的模块，然后是它们引用的模块，然后......等）被复制出静态库并固定到主程序的末尾。整个事情作为单个操作系统“对象”被分页到内存中。
动态库只占用静态库的所有元素，将它们链接在一起（解析内部关系），然后将整个事物映射到内存中。 （请求分页可以使部分内存可以实现。）启动动态程序以便将主程序（将在其自己的模块中“静态”链接）连接到共享的库时，需要一定量的摆弄。全系统。有时这个小提琴会延迟每个连接元素，直到进行给定的调用。在一个非常广泛的，过于概念化的扫描中，可以将静态链接归类为急切加载，将动态分类为延迟加载。
静态库有优点和缺点。
✚没有 DLL地狱（又名依赖地狱）
✚小型运行时混合物的内存占用量小得多
- 对于不同程序的大型运行时过程混合，内存占用空间大得多
- 除了运行相同程序外，不能在进程之间共享任何库代码内存
- 大量的程序（如Linux / Windows / Mac脚印）占用了大量空间，因为printf 等在每个图像中反复复制
- 修复源于图书馆的安全漏洞很难（如果不是不可能）
- 单独更新图书馆即使不是不可能也很困难
✚单独更新图书馆并破坏您的计划很困难，如果不是不可能的话
1。实际上，它们不是 tar（1）格式，但它是相关的。
答案 5 :(得分：0)