Linux 静态链接已失效？

问题描述：

事实上， Linux 上的-static gcc 标志现在不起作用。让我引用 GNU libc FAQ：

2.22. 即使是静态链接程序也需要一些共享库，这对我来说是不可接受的。我该怎么办？

{AJ} 如果没有共享库，NSS（有关详细信息，请键入“info libc“Name Service Switch”）将无法正常工作。NSS 允许使用不同的服务（例如 NIS、文件、db、hesiod），只需更改一个配置文件（/etc/nsswitch.conf），而无需重新链接任何程序。唯一的缺点是现在静态库需要访问共享库。这由 GNU C 库透明地处理。

一种解决方案是使用 --enable-static-nss 配置 glibc。在这种情况下，您可以创建一个仅使用服务 dns 和文件的静态二进制文件（为此更改 /etc/nsswitch.conf）。您需要明确链接所有这些服务。例如：

 gcc -static test-netdb.c -o test-netdb \n>    -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

这种方法的问题在于，您必须将使用 NSS 例程的每个静态程序与所有这些库链接起来。

*{UD} 事实上，再也不能说使用此选项编译的 libc 正在使用 NSS。不再有开关。因此，强烈*
建议不要使用 --enable-static-nss，因为这会使系统上程序的行为不一致。**

考虑到这一事实，现在是否有任何合理的方法可以在 Linux 上创建功能齐全的静态构建，或者静态链接在 Linux 上完全失效了？我的意思是静态构建：

• 行为与动态构建完全相同（行为不一致的静态 nss 是邪恶的！）；

• 适用于 glibc 环境和 Linux 版本的合理变化；

解决方案 1：

我认为这非常令人讨厌，而且我认为因为某个功能在处理某些用例时存在问题而称其“无用”是傲慢的行为。glibc 方法的最大问题是它对系统库（gconv 和 nss）的路径进行了硬编码，因此当人们尝试在不同于其构建目标的 Linux 发行版上运行静态二进制文件时，它就会崩溃。

无论如何，您可以通过设置 GCONV_PATH 来指向适当的位置来解决 gconv 问题，这使我可以使用在 Ubuntu 上构建的二进制文件并在 Red Hat 上运行它们。

解决方案 2：

静态链接再次流行起来！

• Linus Torvalds 支持静态链接，并对 Linux 发行版中的静态链接数量表示担忧（另请参阅此讨论）。

• 许多（大多数？）Go编程语言可执行文件都是静态链接的。

  • 增强的可移植性和向后兼容性是它们受欢迎的原因之一。

• 其他编程语言也做出了类似的努力，使静态链接变得非常容易，例如：

  • Haskell（我正在致力于这项工作）

  • Zig（详情见此处）

• 可配置的Linux 发行版/软件包集（例如NixOS / nixpkgs）可以静态链接其大部分软件包（例如，其pkgsStatic软件包集可以提供各种静态链接的可执行文件）。

• 静态链接可以在链接时更好地消除未使用的代码，从而使可执行文件更小。

• 像musl这样的 libcs​​ 使得静态链接变得简单且正确。

• 一些大型软件行业领导者对此表示认同。例如，Google 正在编写针对静态链接的新 libc（“支持静态非 PIE 和静态 PIE 链接”，“我们目前不打算投资动态加载和链接支持”）。

解决方案 3：

考虑到这个事实，现在是否有任何合理的方法可以在 Linux 上创建功能齐全的静态构建，或者静态链接在 Linux 上是否已经完全失效？

我不知道在哪里可以找到历史参考资料，但是静态链接在 GNU 系统上确实已经失效。（我相信它在从 libc4/libc5 到 libc6/glibc 2.x 的过渡期间已经失效。）

该功能被认为无用，因为：

• 安全漏洞。静态链接的应用程序甚至不支持 libc 的升级。如果应用程序链接到包含 lib 漏洞的系统，那么它将在静态链接的可执行文件中延续。

• 代码膨胀。如果许多静态链接的应用程序在同一系统上运行，则标准库将无法重用，因为每个应用程序都包含其自己的所有内容副本。（尝试du -sh /usr/lib了解问题的严重程度。）

尝试挖掘 10-15 年前的 LKML 和 glibc 邮件列表档案。我很确定很久以前我在 LKML 上看到过一些相关的东西。

解决方案 4：

静态链接在 Linux 世界中似乎不太受欢迎。以下是我的看法。

不了解静态链接吸引力的人通常在内核和低级操作系统领域工作。许多 *nix 库开发人员一生都在处理将一百个不断变化的库链接在一起这一不可避免的问题，这是他们每天都在做的任务。如果您想知道他们可以轻松执行的后空翻，请查看 autotools。

但其他人不应该把大部分时间花在这上面。静态链接将大大有助于避免库的流失。开发人员可以根据软件的时间表升级软件的依赖项，而不是在出现新库版本时被迫这样做。这对于具有复杂用户界面的面向用户的应用程序非常重要，这些应用程序需要控制它们不可避免地依赖的许多低级库的变化。这就是为什么我永远是静态链接的粉丝。如果您可以静态链接交叉编译的可移植 C 和 C++ 代码，那么您几乎已经掌控了世界，因为您可以更快地将复杂的软件交付给世界上不断增长的各种设备。

从其他角度来看，有很多不同意见，但开源软件能够满足所有这些要求，这很好。

解决方案 5：

您必须动态链接到 NSS 服务并不意味着您不能静态链接到任何其他库。常见问题解答只是说，即使是“静态”链接的程序也有一些动态链接库。这并不是说静态链接是“不可能的”或“不起作用”。

解决方案 6：

添加其他答案：

由于其他答案中提到的原因，不建议大多数 Linux 发行版使用它，但实际上有些发行版是专门为运行静态链接二进制文件而制作的：

• 斯塔利

• 莫菲乌斯

• 淀粉Linux

• 彩虹桥

来自stali的描述：

静态 Linux 基于针对每项任务手工挑选的最佳工具集合，并且每个工具都是静态链接的（包括一些 X 客户端，例如 st、surf、dwm、dmenu），

它还旨在通过尽可能避免使用 glibc 和其他臃肿的 GNU 库来减少二进制文件的大小（早期的实验表明，静态链接的二进制文件通常比动态链接的 glibc 文件小！！！）。请注意，这与 Ulrich Drepper 对静态链接的看法完全相反。

由于静态链接二进制文件启动速度更快的附带好处，该分布还旨在提高性能。

静态链接也有助于减少依赖。

您可以在有关静态与动态链接的问题中阅读有关它的更多信息。