静态链接与动态链接

#1 楼

动态链接可以减少总资源消耗（如果多个进程共享同一个库（当然，包括“相同”中的版本））。我相信这是促使它在大多数环境中都存在的论点。这里的“资源”包括磁盘空间，RAM和缓存空间。当然，如果动态链接程序的灵活性不足，则存在DLL崩溃的危险。 />
插件始终要求动态链接。

静态链接可以使二进制文件更容易分发到不同的用户环境（以发送更大，更耗资源的程序为代价）。时间，但这在某种程度上取决于程序的大小和复杂性以及操作系统的加载策略的详细信息。和其他答案。我想指出的是，您要采用的中断方式在很大程度上取决于您计划在何种环境下运行。最小的嵌入式系统可能没有足够的资源来支持动态链接。稍大的小型系统可能会很好地支持动态链接，因为它们的内存足够小，可以使动态链接节省的RAM非常吸引人。正如Mark所指出的那样，功能强大的消费类PC拥有大量资源，您也许可以让便利问题驱使您对此事进行思考。 。

传统上，动态库需要某种粘合层，这通常意味着在函数寻址中需要双重调度或额外的间接层，并且可能花费一点速度（但是函数调用时间实际上是您运行时间的很大一部分吗？）。

但是，如果您运行的多个进程都多次调用同一个库，则相对于使用静态链接而言，使用动态链接时可以节省缓存行（从而赢得运行性能）。 （除非现代操作系统足够聪明，以至于可以注意到静态链接的二进制文件中的相同段。似乎很难，有人知道吗？）

另一个问题：加载时间。您需要在某些时候支付加载费用。何时付款，取决于操作系统的工作方式以及所使用的链接。

请注意，传统上，静态-vs-动态链接不是优化问题，因为它们都涉及到对象文件的单独编译。但是，这不是必需的：原则上，编译器可以将“静态库”“编译”为摘要的AST形式，然后通过将这些AST添加到为主代码生成的AST中来“链接”它们，从而实现全局优化。我使用的系统都没有做到这一点，因此我无法评论它的运行情况。环境））。

#2 楼

动态链接是满足某些许可证要求（例如LGPL）的唯一实用方法。

#3 楼

1）基于以下事实：调用DLL函数始终使用额外的间接跳转。如今，这通常可以忽略不计。在DLL内，i386 CPU的开销更大，因为它们无法生成位置无关的代码。在amd64上，跳转可以相对于程序计数器，因此这是一个很大的改进。

2）这是正确的。通过性能分析进行优化，通常可以赢得大约10-15％的性能。现在，CPU速度已达到其极限，可能值得这样做。

我要补充：（3）链接器可以以更高效的缓存分组方式来安排功能，从而使昂贵的缓存级别未命中率最小化。它还可能特别影响应用程序的启动时间（基于我在Sun C ++编译器中看到的结果）。并且请不要忘记，使用DLL不能执行无效代码消除。取决于语言，DLL代码也可能不是最佳的。虚函数始终是虚的，因为编译器不知道客户端是否会覆盖它。 >
编辑（回答问题，在用户下划线处注明）

这里是有关位置独立代码问题的好资源http://eli.thegreenplace.net/2011/11/03 / position-independent-code-pic-in-shared-libraries /

如前所述，x86在15位跳转范围和无条件跳转和调用中没有其他任何条件的AFAIK。这就是为什么（来自发电机的）功能超过32K一直是一个问题，需要嵌入式蹦床。

但是，在像Linux这样的流行x86操作系统上，您无需担心.so / DLL文件是否不是通过gcc开关-fpic（强制使用间接跳转表）生成的。因为如果您不这样做，则代码就是固定的，就像普通的链接器将其重新定位一样。但是，这样做会使代码段不可共享，并且需要将代码从磁盘到内存的完整映射，并在使用之前将其全部触摸（清空大部分缓存，击中TLB）。等等。当这被认为很慢时。

所以您将不再有任何好处。

我不记得是什么操作系统（Solaris或FreeBSD）给我的Unix构建系统带来了问题，因为我没有这样做，并且想知道为什么崩溃了，直到我将-fPIC应用于gcc。

#4 楼

我同意dnmckee提到的要点，此外：静态链接的应用程序可能更易于部署，因为可能会导致更少或没有其他文件依赖项（.dll / .so）。丢失或安装在错误的位置时出现问题。

#5 楼

进行静态链接构建的一个原因是，要验证您对可执行文件具有完全关闭的功能，即，正确解析了所有符号引用。

作为正在构建和测试的大型系统的一部分使用持续集成，使用可执行文件的静态链接版本运行每晚回归测试。有时候，即使动态链接的可执行文件可以成功链接，我们也会看到符号无法解析，并且静态链接也会失败。拼写错误的名称，因此不会静态链接。无论使用深度优先还是宽度优先评估，动态链接程序都不会完全解析所有符号，因此您可以完成一个没有完全关闭的动态链接可执行文件。

#6 楼

1 /我去过的项目中，对动态链接与静态链接进行了基准测试，并且确定的差异还不足以切换到动态链接（我不是测试的一部分，我只知道结论）
2 /动态链接通常与PIC（位置无关代码，根据其加载地址无需修改的代码）相关联。根据架构的不同，PIC可能会带来另一个速度下降，但是为了获得在两个可执行文件之间共享动态链接库的好处（如果操作系统使用加载地址的随机性作为安全措施，甚至是同一可执行文件的两个进程）共享，PIC是必需的。我不确定是否所有操作系统都可以将这两个概念分开，但Solaris和Linux可以做到，HP-UX可以做到ISTR。链接到“简易补丁”功能。但是，这种“简单补丁”使小补丁的分发变得容易一些，而复杂补丁的分发成为了噩梦。由于错误的版本是令牌，所以我们常常不得不在一切事情上加全力，并且不得不在客户现场跟踪问题。

我的结论是我使用了静态链接，但是： />
对于诸如动态共享依赖的插件之类的东西来说很重要（共享时很重要（多个进程同时使用的大型库，例如C / C ++运行时，GUI库等），这些库经常被管理

如果要使用“简单补丁”，我认为必须像上面的大库一样对库进行管理：它们必须几乎是独立于已定义的ABI，且不能通过修订对其进行更改。

#7 楼

本章详细讨论了Linux上的共享库及其性能含义。

#8 楼

动态链接的最佳示例是库依赖于所使用的硬件。在远古时代，C数学库被认为是动态的，因此每个平台都可以使用所有处理器功能对其进行优化。

更好的示例可能是OpenGL。 OpenGl是一种由AMD和NVidia以不同方式实现的API。而且由于硬件不同，您将无法在AMD卡上使用NVidia实现。因此，您不能将OpenGL静态链接到程序中。动态链接用于使API针对所有平台进行优化。

#9 楼

在类似Unix的系统上，动态链接可能会使“ root”难以使用在偏僻位置安装了共享库的应用程序。这是因为动态链接程序通常不会注意具有根特权的进程的LD_LIBRARY_PATH或其等效项。有时，静态链接可以节省一天的时间。

或者，安装过程中必须找到这些库，但这会使软件的多个版本难以在计算机上共存。

#10 楼

确实很简单。当您更改源代码时，是否要等待10分钟才能构建代码或20秒？我只能忍受20秒。除此之外，我要么剑拔or张，要么开始考虑如何使用单独的编译和链接将其带回舒适区域。

#11 楼

动态链接需要操作系统花费更多时间来找到动态库并加载它。通过静态链接，所有内容都在一起，并且一次性加载到内存中。在这种情况下，操作系统加载的DLL不是您的应用程序随附的DLL，也不是您的应用程序期望的版本。

#12 楼

尚未讨论的另一个问题是修复库中的错误。

使用静态链接，您不仅必须重建库，还必须重新链接并重新分发可执行文件。如果该库仅在一个可执行文件中使用，则可能不是问题。但是需要重新链接和重新分发的可执行文件越多，痛苦就越大。

通过动态链接，您只需重新构建和重新分发动态库就可以了。

#13 楼

Static linking是将链接内容复制到主二进制文件中并成为单个二进制文件时的编译过程。
缺点：

编译时间较长
Dynamic linking是运行时加载链接内容的进程。该技术允许：

升级链接的二进制文件而无需重新编译可提高ABI稳定性的主二进制文件。缺点：

启动时间较慢（应复制链接的内容）
运行时引发链接器错误

#14 楼

静态链接仅给您一个exe，以便进行更改，您需要重新编译整个程序。而在动态链接中，您只需要对dll进行更改，而在运行exe时，这些更改将在运行时获取。通过动态链接（例如Windows）提供更新和错误修复更加容易。

#15 楼

在越来越多的系统中，极高级别的静态链接可能会对应用程序和系统性能产生巨大的积极影响。

我指的是通常被称为“嵌入式系统”的系统，其中许多现在越来越多地使用通用操作系统，并且这些系统用于所有可想像的事物。我通过构建可引导的i386（32位）系统映像（包括内核和其根文件系统）将NetBSD发挥到了极致，后者包含单个静态链接（通过crunchgen）的二进制文件（带有硬链接）所有本身包含所有标准全功能系统程序（最后只有274个）的程序（除工具链以外的大多数程序），并且其大小小于20 MB（并且可能在只有64MB的系统中非常舒适地运行的内存（即使根文件系统未压缩且完全在RAM中），尽管我无法找到这么小的内存对其进行测试。

前面的文章中已经提到静态链接的二进制文件的启动时间更快（并且可能更快），但这只是图片的一部分，尤其是在将所有目标代码链接到同一文件时，尤其是在操作系统时支持直接从可执行文件中按需分页代码。在这种理想情况下，程序的启动时间实际上可以忽略不计，因为几乎所有代码页都已在内存中并且被外壳程序使用（并且可能正在运行的任何其他后台进程），即使请求的程序具有自引导以来从未运行过，因为可能只需要加载一页内存即可满足程序的运行时要求。

但是，这还不是全部。我通常还通过静态链接所有二进制文件来为完整的开发系统构建和使用NetBSD操作系统安装。即使这需要占用大量磁盘空间（x86_64总共约6.6GB，包括工具链和X11静态链接在内的所有内容）（尤其是如果一个磁盘对所有程序都保留了完整的调试符号表，而另外还有约2.5GB），结果仍然整体运行速度更快，并且某些任务甚至比声称共享库代码页的典型动态链接系统使用更少的内存。磁盘很便宜（甚至是快速磁盘），用于缓存常用磁盘文件的内存也相对便宜，但是CPU周期确实不便宜，并且每次启动都要为每个启动的进程支付init的启动成本， CPU远离需要启动许多进程的任务，特别是当一遍又一遍地使用相同的程序（例如开发系统上的编译器）时，CPU就会停止工作。静态链接的工具链程序可以将我的系统的整个OS多体系结构构建时间减少数小时。我尚未将工具链构建到单个ld.so的二进制文件中，但是我怀疑这样做会节省更多的构建时间，因为这将赢得CPU缓存。

#16 楼

静态链接将程序需要的文件包含在一个可执行文件中。动态链接是您通常认为的那样，它使可执行文件仍然需要DLL，并且位于同一目录中（或DLL可能位于系统文件夹中。 br />

#17 楼

另一个考虑因素是您在库中实际消耗的目标文件（翻译单元）数与可用总数的比较。如果库是由许多目标文件构建的，但是您仅使用其中一些符号，则这可能是支持静态链接的一个论据，因为您仅链接静态链接时使用的对象（通常）并且不t通常会携带未使用的符号。如果使用共享库，则该库包含所有翻译单元，并且可能比您想要或需要的库大得多。