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

        从静态库包含目标文件库的意义上来说，它们是真正的库。每个目标文件通常是从单个源文件创建的，并且包含机器代码以及有关代码所需数据的信息。在链接步骤中，链接器将选择必要的目标文件并将其组合为可执行文件。 机器代码的重要部分是跳转，调用和数据指针必须包含实际的内存地址。但是，如果目标文件需要调用另一个目标文件中的另一个函数，则只能使用符号来引用该函数。当链接器将目标文件组合为可执行代码时，符号引用将被解析并转换为实存储器地址。 动态库是可执行代码，可以将其加载到内存中并立即执行。在某些操作系统上，可能还有一个附加步骤，其中通过将可执行代码移动到另一个位置来重新编码代码，这需要将代码内的所有绝对地址移位固定量。此操作仍然比合并目标文件和解析链接程序完成的符号要快得多。 把它们加起来： 静态库包含一些使用符号来引用其他可执行代码的可执行代码 动态库（和可执行文件）包含现在放置在固定位置的可执行代码，使这些符号可以替换为实际内存地址 如果您曾经尝试链接大小合理的项目，则您会注意到，它花费的时间并不短，可能比等待启动应用程序要长。这种解释说明了为什么您不能执行静态库。动态库已经过优化和剥离，除可执行代码外不包含任何内容，这使它们不适合用作静态库。     

        目标文件中的代码未链接。它包含对尚未解决的外部函数的隐式引用。 链接目标文件以创建DLL时，链接程序将遍历所有这些外部引用，并找到可以满足它们的其他库（静态或动态）。通过将函数的主体（或任何主体）包含到DLL中，可以解析对静态库中名称的引用。如果它引用动态库，则DLL和引用函数的名称都包含在DLL中。 最终，没有理由一定是这种情况。从理论上讲，您可以编写加载程序以在每次加载文件时执行所有这些操作。基本上，这只是一种优化：链接器完成了工作中相对较慢的部分。保留了对DLL的引用，但已解决到使加载程序查找并加载目标文件（如有必要）并解析引用的函数相当快的地步。链接器执行其工作时，它会扫描一长串的定义列表以查找您关心的定义，从而做得更多，这要慢得多。     

注意：以下答案不是平台无关的，而是特定于基于ELF的系统和其他一些类似的系统。其他人可以填写其他系统的详细信息。 什么是静态库？ 静态库是存档中“ 0”个文件的集合。每个文件都可以包含对未定义符号的引用，链接器必须对此文件进行解析，例如，您的库可能具有对“ 1”的引用。该库未提供有关在何处可以找到ѭ1indication的任何指示，希望链接器在要求链接的其他库之一中找到它。 假设您的库包含以下代码：

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

如果应用程序仅使用

read_png

和

write_png

，则其他代码段将不会加载到可执行文件中（

handle_error

除外，from6ѭ从ѭ4called和

write_png

调用）。 我们无法在运行时加载静态库，因为： 链接器不知道在哪里可以找到外部对象，例如

printf

。 会很慢。动态库已针对快速加载进行了优化。 静态库没有名称空间的概念。我无法定义自己的

handle_error

，因为它会与库的定义冲突。 什么是动态库？ ELF系统上的动态库是与可执行文件相同类型的对象。它还导出更多符号，可执行文件只需要导出

_start

。动态库经过优化，因此可以将整个对象直接映射到内存中。 如果您在动态库中调用了“ 1”，那么除了静态库的要求之外，还有一些其他要求： 您必须指定哪个库具有

printf

。 您必须以一种特殊的方式调用该函数，以使链接器可以插入

printf

的地址。在静态库中，链接器只能修改您的代码并直接插入地址，但是共享库则无法实现。 我们不想使用动态库静态链接，因为： 我们不能仅链接动态库的一部分。即使我们的可执行文件从不调用ѭ15，它也会被包含在内，因为动态库是全有还是全无。 即使很小，函数调用的额外开销也是浪费的。 摘要 编译看起来像这样：

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

静态库是一个充满了尚未链接对象的归档文件。还有很多工作要做。 共享库是链接的最终产品，可以随时加载到内存中。 静态库是最早发明的。如果两者是同时发明的，那么它们可能会更加相似。     

        根本没有理由不能将静态库（

.a

）文件用作动态库，无法在程序启动时甚至在运行时动态加载和链接它们。但是，它们尚未经过专门编译并准备在任意地址运行内存映射（甚至对齐不一定正确！），因此加载程序代码将不得不分配内存，从

.a

文件中读取必要的对象到此文件中。内存，并对其进行重大修改。当然，这些内存都不是可共享的。因此，这可能是一个非常糟糕的主意...     

静态lib == tarball，而动态==连续图像部分链接 静态库只是

.o or

.obj`文件的tarball1。当链接一个可执行文件时，将被引用的模块（以及它们所引用的模块，然后是它们所引用的模块，然后...等等）从静态库中复制出来并粘贴到主程序的末尾。这整个东西作为单个OS“对象”分页到内存中。 动态库只吸收静态库的所有元素，将它们链接在一起（解决壁间关系），然后将整个对象映射到内存中。 （按需分页可以使部分内存存在。）在启动动态程序时需要一定程度的摆弄，以便将主程序（将“静态”链接到其自身模块中）连接到该库上。在系统范围内共享。有时，这种摆弄会延迟每个链接元素，直到发出给定调用为止。在一个非常广泛的，概念过度的扫描中，可以将静态链接归类为渴望加载，而将动态链接归类为延迟加载。 静态库有优缺点。 ✚没有DLL的地狱（aka依赖地狱） for内存占用空间小得多，适用于小型运行时混合流程 −对于不同程序的大型运行时混合处理，内存占用量更大 −进程之间不能共享任何库代码内存，除非它们正在运行同一程序 −由于printf等在每个图像中一遍又一遍地重复，因此大量程序（例如Linux / Windows / Mac足迹）占用了大量空间。 −很难甚至不可能修复源自库的安全漏洞 −很难甚至不可能单独更新库 alone很难甚至不可能独自更新一个库并破坏程序 1.实际上，它们不是tar（1）格式，而是相关的。     

        区别在于： 静态库以及编译和链接 动态库已链接 参考文献 避免LD_LIBRARY_PATH 共享库HOWTO