更新 glibc 可能会导致系统崩溃吗？

Question

假设我有一个程序依赖于较新的 glibc 版本，该版本在系统中通过包不可用。它给出：

version `GLIBC_2.xxx' not found

一种解决方案是使用 glibc 静态编译二进制文件。

另一种被许多人认为“不安全”的解决方案是放置更新的libc.so.6而不是操作系统提供的。

如果包含先前的 ABI 端点，那么第二个解决方案究竟有多不安全或不是一个坏主意libc.so.6？

例如，如果我运行，strings /usr/lib/libc.so.6 | grep --perl-regexp "^GLIBC_"我可以看到很多 ABI 版本，例如：

...
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
...

因此，如果我使用其中libc.so.6包含其他glibc ABI 版本的较新版本覆盖，它如何破坏旧应用程序或导致系统损坏？

或者不是……？:)

Answer 1

通常，为较旧的 glibc 版本编译的二进制文件将在具有较新 glibc 的系统上正常运行，因为 glibc 向后兼容并自动处理对其应用程序二进制接口 (ABI) 的更改。它通过使用符号版本控制来实现这种魔法，其中基本上每个符号都附加了一个指定其 glibc 版本的标签。

如果函数调用的语义发生变化，glibc 将包含两个版本，一个用于旧语义，另一个用于新语义，因此每个函数都标有其版本。链接器会将这两个版本视为两个不同的函数。

这种复杂的机制是必需的，因为 glibc 不是一个文件，而是由许多部分（超过 200 个共享库）组成。

glibc 版本的向后兼容性正在持续跟踪中。您可以查阅 ABI 实验室报告以了解 glibc 的 API/ABI 更改审查。该报告由abi-compliance-checker和 abi-tracker工具生成。

对于您的问题：

因此，如果我使用带有额外 glibc ABI 版本的较新 libc.so.6 覆盖，它如何破坏旧应用程序或导致系统损坏？或者不是……？

Glibc 兼容性不是万无一失的，但我相信您将不得不回到在相当旧的 Linux 版本上编译的产品来破坏它。我还想说，当在不同于编译位置的 Linux 版本上运行时，产品可能不仅因为 glibc 而崩溃。

所以我能给出的最好答案是：
“它不应该破坏任何东西，而且很有可能它不会”。

有关更多信息，请参阅：