c - 在 Linux 中分发针对非标准 glibc(即 glibc 2.24)编译的 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

When can I expect that Ubuntu will support glibc 2.24?

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

Is it possible to have two libc versions in a system?

是的，请参阅 this answer 。但这不是一个微不足道的提议，而且大多数理智的客户都会对拥有一个他们需要自己构建并保持修补的单独 GLIBC 的想法犹豫不决(如果你想简单地给他们一个预构建的副本，你就疯了^H ^H 不明白你在注册什么)。

Is it possible to link libc statically?

也许吧。如果您的应用程序使用 NSS(gethostbyname 等；大多数非平凡的应用程序都这样做)，那么即使是静态链接的应用程序也将无法运行(您将收到一条链接时警告，如 this one )。

Indeed, I would only need the stdio part. Is it possible to use only stdio from 2.24, would this give any benefit?

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