C静态库不受欢迎吗？[关闭]

共享库有两个参数：

1. 它有助于减少磁盘空间。
2. 共享库更新后，取决于它的所有二进制文件都会更新。

共享库主要有一个缺点：

• 他们可以引入依赖地狱。

在台式计算机上，第一个优点实际上不再成立。如今，浪费磁盘空间已不是什么大问题。

拥有静态二进制文件将使我们能够获得更好的程序包管理器-我的意思是，依赖关系已经成为过去。添加程序就是添加二进制文件。最后是一个文件夹，让它处理其文件。删除程序就是删除该文件。依赖关系？走了

第二个优势仍然存在，但我认为台式机上静态二进制文件的优势胜过它。我的意思是，尽管具有共享库的优势，但即使是Go这样的新语言也可以编译所有二进制文件，这是因为它具有便利性。

既然共享库的主要优点之一不再重要，那么C静态库是否仍然不受欢迎？如果是这样，为什么？

您的问题的前提是有缺陷的。令人信服的是坚持教条和绝对原则，却不了解其背后的基础（货物崇拜编程？）。

链接的SO答案在该主题中是一项有趣的研究-问题是为什么带有-static选项的编译不起作用，您链接到的答案无非是不使用静态链接。如果不讨论其不好的原因，并要求OP使用动态链接。它的不幸之处在于，它被标记为正确答案（后面的答案具有两倍的票数，是对OP的问题的正确答案），因为尽管存在正确的答案，但它深深地隐藏在教条主义的观点之中。

真正的问题是静态链接与动态链接的优缺点是什么，何时会比另一个更受欢迎。

从开发人员的角度来看，动态链接通常可以大大加快编译/链接/测试循环的速度。

从软件包管理的角度来看，以libGL为例。我的程序包管理器中提供了大约十二种不同的实现方式，其中一些是通用的，还有一些是针对特定图形卡的。如果它不是动态链接的，则每个程序必须有十几个与libGL链接的版本，否则您将不得不设计一个附加的抽象层，其效率不如函数调用。

考虑一下像Qt这样的流行库中的安全问题。使用动态链接，我可以只更新一个软件包，而不必识别，重新编译和部署Qt中链接的每个软件包。

静态链接在独立部署的封闭源应用程序中可能具有优势，但是在开源软件包管理中，它带来的伤害大于帮助。

基本上，您的理由＃2 是Linux 发行维护者强烈建议使用共享库。对他们来说，真正重要的是，例如，当有人在zlib中发现一个安全漏洞时，他们不必重新编译使用zlib的每个程序-不仅这样做会花费更多的CPU周期重新编译后，使用发行版的每个人都必须重新下载所有这些程序。同时，在发行版提供的一组软件包中，依赖关系地狱不是问题，因为所有内容都经过测试可与该组库一起使用。

如果您要构建需要分发库中没有的库的第三方软件，则静态链接这些库可能比选择替代方法麻烦些，这很好。

要知道的另一件事是，如果库是静态链接的，则GNU libc和GCC libstdc++都具有无法可靠运行的组件。最常见的问题是dlopen，因为您要加载的任何模块dlopen本身都是动态链接的libc.so.6。因此，这意味着现在您在地址空间中拥有C库的两个副本，并且当他们不同意内部malloc数据结构的哪个副本（例如）具有权威性时，就会发生欢喜。更糟糕：不出现功能一大堆有什么关系dlopen，像gethostbyname和iconv，使用dlopen在内部（这样它们的行为是可在运行时配置的）。幸运的是，用于libc和libstdc ++的ABI非常稳定，因此您不可能遇到动态链接它们的问题。

我同意mattnz的最后一点：这个问题是一个充满挑战的问题。它假定静态链接是错误的。我可以想到以下两个原因：

• 静态链接是安全的：如果更新了共享库，使得应用程序使用新的库（也许新的库覆盖了旧的库，或者旧的库已被删除），则可能会带来新版本破坏应用程序的风险。这是该应用程序的正式更新范围之外的代码更改。可能尚未经过测试。静态链接通过不与外部共享库来避免这种情况。由于这种风险，我认为这对共享库是不利的。如果共享库的新版本引入了会破坏某些较旧应用程序的新错误，该怎么办？

• 静态链接可确保应用程序更加独立。虽然共享库可以与主要可执行文件并置，但是它们通常存放在共享位置。静态链接的应用程序更容易确保“可移植”，即“不需要更改操作系统所拥有的文件，目录或设置”（例如Windows目录，注册表，/ etc）。

静态和动态库都有各自的用途。查看范围内的单个应用程序，我们对需要什么和不需要什么有了不同的想法。

静态链接极大地简化了应用程序部署。不必检测和处理不同的版本。刚烘烤并部署。

动态库的明显优势是能够独立应用更新。

这就是我讨厌Maven和其他类似的Java动态链接项目构建器的原因之一。他们希望在指定的URL上永远可以使用单个库版本。由于所有源和jar都已消失，因此没有人理解十年来出现的问题，当时没人能编译该应用程序。