我刚刚发现，glibc 2.23有一个关于工作室函数fmemopen()的错误，参见例如在使用fmemopen打开的FILE*上使用rewind()。(这里描述的错误行为并不是唯一的。如果缓冲区的大小超过8192字节，问题就更严重了…)
现在我正在考虑使用新发布的glibc 2.24，它已经修复了这个错误。然而，我的目标用户环境是Ubuntu计算机，我想Ubuntu支持glibc 2.24还需要一段时间。
那么，当我尝试分发我的代码时会遇到什么问题呢?
或者，一些相关的问题:
- 我什么时候能期待Ubuntu支持glibc 2.24?
- 是否可以在一个系统中有两个libc版本?
- 是否可以静态链接libc ? 事实上，我只需要工作室部分。是否有可能只使用2.24版本的studio，这会带来任何好处?
我什么时候可以期待Ubuntu支持glibc 2.24?
Ubuntu刚刚发布了带有GLIBC-2.23链接的16.04版本。你可以期待下一个LTS版本将在2年后发布。即使到那时，你也可以预期你的客户在未来5年内不会有最新的版本。
有可能在一个系统中有两个libc版本吗?
是的，看看这个答案。这不是一个微不足道的提议，大多数理智的客户会拒绝拥有一个独立的GLIBC，他们需要自己构建和修补(如果你只是想给他们一个预构建的副本，你是疯了^H^H不明白你在注册什么)。
是否可以静态链接libc ?
也许。如果您的应用程序使用NSS (gethostbyname等);大多数不重要的应用程序都可以)，那么即使是静态链接的应用程序也无法工作(你会得到一个像这样的链接时间警告)。
事实上，我只需要工作室部分。是否有可能只使用2.24版本的studio，这会带来任何好处?
你不能轻易地将工作室与其他工作室分开。即使您设法生成了一个工作的二进制文件，它正确工作的机会也是很小的。