c++ - 为什么不鼓励静态链接 glibc？

Question

大多数在线资源表明您可以静态链接 glibc，但不鼓励这样做；例如centos package repo :

The glibc-static package contains the C library static librariesfor -static linking. You don't need these, unless you link statically, which is highly discouraged.

这些消息来源很少(或从不)说明为什么这是一个坏主意。

Answer 1

其他答案给出的理由是正确的，但不是最重要的原因。

glibc 不应该被静态链接的最重要原因是它在内部大量使用了dlopen。 , 加载 NSS ( Name Service Switch ) 模块和 iconv转换。模块本身引用 C 库函数。如果主程序与 C 库动态链接，那没问题。但如果主程序与 C 库静态链接，dlopen 必须去加载 C 库的第二个拷贝以满足模块的加载要求。

这意味着你的“静态链接”程序仍然需要一个 libc.so.6 的拷贝出现在文件系统上，加上 NSS 或 iconv 或其他任何东西模块本身，加上模块可能需要的其他动态库，如 ld-linux.so.2、libresolv.so.2 等。这不是人们通常的当他们静态链接程序时需要。

这也意味着静态链接的程序在其地址空间中有两个 C 库拷贝，它们可能会争夺使用谁的 stdout 缓冲区，谁可以调用 sbrk 带有非零参数，诸如此类。 glibc 内部有一堆防御性逻辑试图让这项工作发挥作用，但从来没有保证能够工作。

您可能认为您的程序不需要担心这一点，因为它从不调用 getaddrinfo 或 iconv，但语言环境支持使用 iconv 内部，这意味着 任何 stdio.h 函数 都可能触发对 dlopen 的调用，而您无法控制它，用户的环境变量设置。

如果你的程序确实调用iconv，那么事情会变得更糟，尤其是当“静态链接”的可执行文件构建在一个发行版上时，然后复制到另一个。 iconv 模块有时位于不同发行版的不同位置，因此在 Red Hat 发行版上构建的可执行文件可能无法在 Debian 上正常运行，这与人们想从静态链接的可执行文件中得到什么。