我有一个需要在各种古老的 Linux 平台上运行的应用程序，所以我将它与 GNU libc 2.1.2 链接。但是目前我正在考虑构建应用程序的 UNICODE 版本。问题是我链接的 libc 没有某些基本功能，如 vswprintf。
是否可以使用 libc 2.4 并将其与我的应用程序一起提供（作为单独的文件 libc.so.6）？会不会违反 GNU libc 许可？
还有其他解决方案吗？也许有一个可用的 vswprintf 函数（我相信编写这个函数不是很有效）。到目前为止，我唯一的其他选择是将所有内容都转换为 char* 并使用 vsprintf。
【问题讨论】：
听起来很糟糕。古老的平台应该有古老的系统调用，带有古老的原型。阅读here
世界变了，系统调用也变了。由于不得破坏旧的二进制文件，因此与任何给定系统调用号相关联的语义必须保持完全向后兼容。
在实践中发生的事情是两件事之一：要么得到一个新的 并使用新名称和号码改进了系统调用，以及 libc 用于调用旧调用的例程更改为使用新调用 一个，或者新呼叫（使用新号码）使用旧名称，而旧名称 call 在其名称前加上“旧”前缀。
【讨论】：
是否可以使用 libc 2.4 并将其与我的应用程序一起提供（作为单独的文件 libc.so.6）？
是和不是。你不能分发just libc.so.6，原因解释here。
您必须分发几乎完整的 GLIBC 构建，并且必须将其安装在固定位置（因为您无法轻松更新到在构建时硬编码到可执行文件中的 ld-linux 的路径）。无论如何，您的构建可能无法在足够旧的内核上运行。
它会违反 GNU libc 许可证吗？
如果您提供用于构建 libc 的资源并使用动态链接，则不会（但我不是律师，您应该咨询此类法律问题）。
还有其他解决方案吗？
BSD libc 似乎有一个宽字符 printf 的 implementation，您可以重复使用它，如 do musl 和 uClibc。请注意，这可能是一个重要的命题。
【讨论】：