为什么不建议静态链接 glibc？

问题背景

1. 工作环境中，由于要兼容低版本 Linux 发行版本，C/C++ 应用程序的编译环境还是古老的 CentOS-5，其 glibc 版本是 2.5，应用程序动态链接 glibc-2.5 版本生成的可执行文件就支持在所有 glibc-2.5+ 的 Linux 系统
2. 但在古早 Linux 发行版上做开发还是比较蛋疼的事情，官方早已不维护更新，内核版本低，甚至不在很多软件的支持范围内
3. 如果静态链接 glibc 就不需要关心系统中 glibc 的版本了，是否能解决问题呢？但印象里有看到过不建议静态链接 glibc 的说法，但没有深究过根本原因，今天因为某些原因再次想到这个问题，索性就简单检索了一下问题并记录以备忘

遍历已有

• Why is statically linking glibc discouraged? - stackoverflow

问题原因

从已有参考来看，不建议静态链接 glibc 主要有两个原因：

1. glibc 中某些模块是运行时加载（如 nss、iconv），且这些模块中同样引用了 c 库中的符号，这些模块本身可没有静态链接 glibc，这意味着
   1. 当使用这些模块时，还是会产生对 glibc 的依赖，乃至于对动态链接器库或者其它库的依赖，这显然跟静态链接 glibc 的初衷相悖（合着到头来白静态链接了）
   2. 比上一个影响更严重的是，进程虚拟空间中加载了多份 c 库的副本，某些资源的访问会出现冲突（比如 使用哪一份 stdout 缓冲区的使用）
2. 静态链接 libc 意味着，在可执行文件中固化了所有 c 库的实现，但要明确的东西是：
   1. 应用程序和 libc 之间的接口是有标准规范的，比如 POSIX、C/C++ 标准等
   2. libc 和操作系统之间的接口是非标准的，我们静态链接 libc 相当于默认有这么一层约束，而这个约束并没有谁能提供保障