我的CentOS 6.0服务器glibc-2.12-1.7.el6.x86_64运行许多开源服务和一些我自己的 C 程序。
为了修复 Ghost 漏洞，我需要将其更新到glibc-2.12-1.149.el6_6.5.
由于版本差异似乎很大。
我想知道是否需要重新编译我的 C/C++ 应用程序甚至某些开源服务？
因为测试一切几乎是不可能的，我该如何测试它们？
我读到有些人因为应用程序中出现段错误而不得不恢复更新。
答案1
Linux 应用程序几乎总是使用动态链接到 C 库，这意味着它不会编译到它们中 - 它是在运行时链接的。这意味着如果您已经升级了 C 库，则无需执行任何其他操作。
然而，虽然这很不寻常，但用静态链接的 glibc 构建东西也不是不可能的。最好的办法就是查看相关应用程序的文档。如果这是惯例，那么几乎可以肯定它是明确的。
您可以使用检查可执行文件file。它应该在输出中显示“动态链接”。我思考这样的二进制文件仍然有可能合并静态 glibc ——但这将是非常迟钝的。双重检查的方法是：
ldd whatever | grep libc.so
whatever您要检查的二进制文件在哪里。你应该得到一些输出。如果没有，请在这里发表评论，这样我就可以吃了我的帽子，因为我不相信有人会创造这样的东西。
如果您确实找到了实际的静态二进制文件，这并不意味着它一定使用 glibc。您必须通过咨询源代码树、文档或开发人员来确认这一点。
我读到有些人因为应用程序中出现段错误而不得不恢复更新。
我也见过第二手和第三手的。但我实际上还没有看到这种情况的具体描述。老实说，我认为这不太可能。
答案2
首先，红帽企业 Linux 尽可能长时间地保留其软件包的基础，并保持严格的二进制兼容性。如果您分析 2.12-1.7.el6.x86_64 与 2.12-1.149.el6_6.5 的版本glibc（我假设此处缺少 .x86_64），您会发现两者都是上游版本 2.12，本地（RHEL）版本是 1.7相对于 1.149（即大约 142 组补丁）。一个用于 el6（即 RHEL 6），另一个用于 el6_6.5（即捆绑到 RHEL 6“新版本”中的第五轮更新）。它们应该非常接近，没有用户可见的差异（显然除了错误修复）。
绝大多数程序动态链接到它们的库（磁盘和内存中只有一个库副本，常用符号可供所有人使用，从而提供更好的性能），因此接下来会特别修复库更新后程序启动的时间。仅在极少数情况下，这可能需要重新编译程序本身（例如，如果标头中的内联函数或宏被证明以破坏性方式出错）。
静态链接程序包含库的代码（这种情况越来越罕见！）可以变得脆弱如果他们碰巧使用了损坏的代码在图书馆。