Google开发人员希望为LLVM开发自己的libc

LLVM邮件列表中介绍了一位Google开发人员，主题是开发 跨平台标准C库 （libc）在LLVM项目的框架内。

有几个原因， Google对当前的libc不满意 （glibc，musl） 该公司正按计划开发新的实施方案，他打算将其开发为LLVM的一部分。 LLVM的开发最近已用作构建Google工具的基础。

计划逐步开发，逐步增加功能。 建议第一选项采用应用程序和libc系统之间的中间层的形式，将从中借用未实现的功能。

在达到一定的功能水平之后，新的Libc可以完全替代Libc系统。

计划从对x86-64架构，Linux和静态绑定的支持开始（第二阶段将实现动态加载，打包和其他架构）。

该项目仍处于开发的初始阶段，但是已经定义了基本目标：

• 模块化和开发符合提供粒度库的理念，而不是一个整体。
• PIE模式下的静态链接支持 （与位置无关的可执行文件）且没有PIE。 为静态链接的可执行文件提供CRT（C运行时）和PIE加载程序。
• 支持大多数C库功能 POSIX插件的标准配置和现有应用程序中要求的某些特定于系统的扩展。
• 谨慎对待特定扩展名 提供商提供的信息，仅在必要时添加它们。 对于第三方扩展支持，建议使用Clang和libc ++项目方法。
• 使用LLVM工具在开发中使用最佳实践，例如从一开始就使用消毒剂和取消测试。

一位活跃的LLVM开发人员表示 作为LLVM工具包的一部分提供libc 这并非没有意义，但通常他们有需要使用musl库， 它写得很好，支持多种体系结构，并提供必要的功能，包括动态链接。

将Musl并入LLVM中以及将其开发为与主要项目同步的分支是有道理的。

Musl项目的作者也表达了他的观点，他试图论证为什么Google的提案以及在LLVM交付中包含Libc是非常糟糕的主意：

开发和维护正确，兼容和高质量的libc是一项非常艰巨的任务。 问题不在于代码量，而在于提供正确的行为。

考虑到用C / C ++编写的庞大应用程序存储库以及Libc使用其运行时使用其他语言的应用程序，因此接口实现存在困难。

在不考虑细微差别的情况下采用额头方法只会导致以下事实：许多现有程序将无法与Libc配合使用，但这样的项目将对消费者不感兴趣。

企业发展可能会破坏Libc，但推动了广泛的使用，这将导致需要添加黑客来确保应用程序的兼容性。

在公司开放项目的主持下进行的开发将推动针对公司的需求和决策的覆盖，从而损害社区的利益。

例如，在识别由您自己的另一个程序的错误引起的问题的情况下，在受控制的开发中，保证Libc与该错误的兼容性比纠正错误本身要容易得多。

Apple为此目的使用BSD libc分支，而Google使用Fuchsia分支。 Musl的开发人员经验表明，律师与他联系主要是为了澄清许可问题。

数据来源： http://lists.llvm.org