在某些情况下,选择静态链接而不是动态链接或反之,是否有令人信服的性能原因?我听过或读过以下内容,但我对这个主题了解不够,无法保证其真实性。
1)静态链接和动态链接在运行时性能上的差异通常可以忽略不计。
如果使用使用概要数据优化程序热路径的分析编译器,2)(1)是不正确的,因为使用静态链接,编译器可以优化你的代码和库代码。使用动态链接,只能优化您的代码。如果大部分时间都花在运行库代码上,这可能会有很大的不同。否则,(1)仍然适用。
在某些情况下,选择静态链接而不是动态链接或反之,是否有令人信服的性能原因?我听过或读过以下内容,但我对这个主题了解不够,无法保证其真实性。
1)静态链接和动态链接在运行时性能上的差异通常可以忽略不计。
如果使用使用概要数据优化程序热路径的分析编译器,2)(1)是不正确的,因为使用静态链接,编译器可以优化你的代码和库代码。使用动态链接,只能优化您的代码。如果大部分时间都花在运行库代码上,这可能会有很大的不同。否则,(1)仍然适用。
当前回答
在类unix系统上,动态链接会使“root”很难使用安装在偏僻位置的共享库的应用程序。这是因为对于具有根权限的进程,动态连接器通常不会注意LD_LIBRARY_PATH或其等效内容。有时,静态链接可以解决问题。
另外,安装过程必须确定库的位置,但这可能会使计算机上的多个软件版本难以共存。
其他回答
动态链接是满足某些许可要求(如LGPL)的唯一实用方法。
这真的很简单。当您在源代码中进行更改时,您希望等待10分钟或20秒来构建它?我只能忍受20秒。除此之外,我要么拿出剑来,要么开始考虑如何使用单独的编译和链接将其带回舒适区。
我同意dnmckee提到的观点,另外:
静态链接的应用程序可能更容易部署,因为很少或没有额外的文件依赖项(.dll / .so),当它们丢失或安装在错误的位置时,可能会导致问题。
执行静态链接构建的一个原因是验证可执行文件是否完全关闭,即所有符号引用都正确解析。
作为使用持续集成构建和测试的大型系统的一部分,夜间回归测试使用可执行文件的静态链接版本运行。偶尔,我们会看到一个符号无法解析,静态链接会失败,即使动态链接的可执行文件可以成功链接。
这种情况通常发生在共享库中位置较深的符号有拼写错误的名称,因此不能进行静态链接时。无论使用深度优先还是宽度优先求值,动态链接器都不能完全解析所有符号,因此您可以完成一个没有完全闭包的动态链接可执行文件。
静态链接是在编译时将链接的内容复制到主二进制文件中并变成单个二进制文件的过程。
缺点:
编译时间更长 输出二进制更大
动态链接是在运行时加载链接内容的过程。这项技术允许:
升级链接二进制文件而不重新编译主二进制文件,增加ABI稳定性[关于] 是否有单个共享副本
缺点:
开始时间较慢(应复制链接内容) 链接器错误在运行时抛出
[iOS静态vs动态框架]