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