在 Linux（即 glibc 2.24）中分发针对非标准 glibc 编译的 C 程序需要什么？

Question

我刚刚发现，glibc 2.23 有一个关于 stdio 函数 fmemopen() 的错误，参见例如Using rewind() on a FILE* opened with fmemopen。 （那里描述的错误行为并不是唯一的。如果缓冲区的大小超过 8192 字节，问题会变得更加严重......）

现在我正在考虑使用新发布的 glibc 2.24，它已经修复了这个错误。但是，我的目标用户环境是 Ubuntu 计算机，我想 Ubuntu 支持 glibc 2.24 开箱即用还需要一些时间。

那么，当我尝试分发我的代码时会遇到什么问题？

或者，一些相关的问题：

• 什么时候可以期待 Ubuntu 支持 glibc 2.24？
• 一个系统中是否可以有两个 libc 版本？
• 是否可以静态链接 libc？
• 确实，我只需要 stdio 部分。是否可以仅使用 2.24 中的 stdio，这会带来什么好处吗？

Answer 1

我什么时候可以期待 Ubuntu 支持 glibc 2.24？

Ubuntu 刚刚发布了带有 GLIBC-2.23 link 的 16.04 版。您可以预期下一个 LTS 版本将在 2 年内发布。即便如此，您仍可以预期您的客户在 5 年内不会有最新版本。

一个系统可以有两个 libc 版本吗？

是的，请参阅this answer。不过，这不是一个简单的提议，大多数理智的客户会拒绝拥有一个单独的 GLIBC 的想法，他们需要自己构建并保持修补（如果您只想给他们一个预构建的副本，那么您就是疯了^H ^H 不明白你在注册什么）。

是否可以静态链接libc？

也许吧。如果您的应用程序使用 NSS（gethostbyname 等；大多数重要的应用程序都使用），那么即使是静态链接的应用程序也将无法工作（您将收到类似 this one 的链接时间警告）。

确实，我只需要 stdio 部分。是否可以仅使用 2.24 中的 stdio，这会有什么好处吗？

您不能轻易地将 stdio 与其他部分分开。即使您确实设法生成了一个工作二进制文件，它正确工作的可能性也很小。