我刚刚发现，glibc 2.23有一个关于stdio函数fmemopen（）的bug，参见例如Using rewind() on a FILE* opened with fmemopen。 （描述的错误行为不是唯一的。如果缓冲区的大小超过8192字节，问题会变得更多......）
现在我正在考虑使用新发布的glibc 2.24，它修复了这个bug。但是，我的目标用户环境是Ubuntu计算机，我想它仍然需要一些时间，直到Ubuntu支持glibc 2.24开箱即用。
那么，当我尝试分发代码时，我会遇到什么问题？
或者，一些相关的问题：
答案 0 :(得分：2)
我什么时候可以预期Ubuntu会支持glibc 2.24？
Ubuntu已经发布了版本16.04与GLIBC-2.23 link。您可以预期下一个LTS版本将在2年内发布。即使这样，您也可以期望您的客户在未来5年内没有最新版本。
系统中是否可以有两个libc版本？
是的，请参阅this answer。然而，这并不是一个微不足道的主张，大多数理智的客户都不愿意想要建立一个单独的GLIBC，他们需要自己构建并保持修补（如果你想简单地给他们一个预建的副本，你就是疯了^ H ^ H不明白你要注册的是什么。
是否可以静态链接libc？
也许。如果您的应用程序使用NSS（gethostbyname等;大多数非平凡的应用程序都可以），那么即使是静态链接的应用程序也行不通（您将收到类似this one的链接时警告。）
确实，我只需要stdio部分。是否可以仅使用2.24中的stdio，这会带来任何好处吗？
您无法轻易地将stdio与其他人区分开来。即使你设法生成一个有效的二进制文件，它正确的可能性也很小。