为什么不使用静态链接更多？

Question

我理解动态链接的好处（旧代码可以自动利用库升级，它的空间效率更高），但它肯定有缺点，特别是在异构Linux生态系统中。这使得分发一个与分发无关的二进制文件变得很困难。并使之前工作的程序更容易破坏，因为系统升级会破坏向后兼容性或将回归引入共享库。

鉴于这些缺点，为什么动态链接似乎是如此普遍受欢迎？为什么很难找到静态链接的，与发行版无关的Linux二进制文件，即使是小型应用程序也是如此？

Answer 1

有三个重要原因：

1. GNU libc不支持与自身的静态链接，因为它广泛内部使用dlopen。 （这意味着与其他任何东西的静态链接不太值得，因为你无法在不替换C库的情况下获得完全静态二进制文件。）
2. 发行版不支持与其他任何内容的静态链接，因为它会增加图书馆存在安全漏洞时必须完成的工作量。
3. 发行版对分发不可知的二进制文件没有任何兴趣。他们想要获取源并自己构建它。

您还应该记住，Linux-not-Android软件生态学完全基于源代码。如果您要发送二进制文件而且您不是分发供应商，那么您就是在做错了。

Answer 2

我们更喜欢动态链接有几个原因：

1. <强>许可即可。这是LGPL的一个特殊问题，尽管还有其他类似限制的许可证。

   基本上，我发送一个针对LGPL libfoo.so。*构建的二进制文件是合法的，甚至可以为您提供该库的二进制文件。我有各种各样的职责，比如响应LGPL库的源代码请求，但重要的是我不必为你的程序提供源代码。由于glibc是LGPL并且几乎Linux盒子上的每个二进制文件都链接到它，因此默认情况下仅强制动态链接。

2. 带宽费用。人们喜欢说带宽是免费的，但这只是在原则上才是真的。在许多实际情况中，带宽仍然很重要。

   我公司的主要基于C ++的系统包含大约4 MB的RPM，在大多数客户的站点上通过慢速DSL上行链路上传需要几分钟。我们仍然只有一些客户可以通过调制解调器访问，对于那些上传是“启动它，然后去吃午餐”的问题。如果我们运送静态二进制文件，这些包将会更大。我们的系统由几个合作程序组成，其中大多数程序链接到同一组动态库，因此RPM将包含相同共享代码的冗余副本。压缩可以挤出一些，但为什么要一次又一次地为每次升级发货呢？

3. <强>管理即可。我们链接的许多库都是操作系统发行版的一部分，因此我们可以独立于我们的程序免费更新这些库。我们无需管理它。

   我们单独发布一些不属于操作系统的库，但它们的更改频率要低于我们的代码。通常，这些在我们构建服务器时安装在系统上，然后再也不会更新。这是因为我们通常对稳定性比对这些库中的新功能更感兴趣。只要它们正在工作，我们就不会碰它们。