Google 的开发人员建议为 LLVM 开发自己的 libc

来自Google的开发者之一 提出 在 LLVM 邮件列表中，有关作为 LLVM 项目一部分的多平台标准 C 库 (Libc) 的开发。 由于多种原因，Google 对当前的 libc（glibc、musl）并不满意，该公司正在开发新的实现，建议将其作为 LLVM 的一部分进行开发。

LLVM 开发最近被用作构建 Google 汇编工具的基础。 主要想法是，如果 Google 已经开始开发其 libc，那么为什么不立即将其系统开发为 LLVM 的一部分，LLVM 已经提供了自己的 C++ 标准库（Libc++），但没有类似的 C 标准库（libc）。

开发计划分阶段进行，逐步增加功能。 第一个选项建议设计为应用程序和系统 Libc 之间的一个层，从中借用尚未实现的功能。 当达到一定的功能水平后，新的Libc可以作为系统Libc的完全替代品。 我们计划首先支持 x86-64 架构、Linux 和静态链接（动态加载、链接和其他架构将随后实现）。

该项目仍处于开发初期阶段，但基本目标已经确定：

• 模块化和开发遵循提供细粒度库而不是单一集合的理念；
• 支持模式中的静态链接 馅饼 （与位置无关的可执行文件）并且没有 PIE。 为静态链接的可执行文件提供CRT（C运行时）和PIE加载器；
• 支持大多数标准 C 库函数，并添加了 POSIX 功能和现有应用程序所需的一些特定于系统的扩展；
• 请小心供应商特定的扩展，仅在必要时添加它们。 关于第三方扩展的支持，建议采用Clang和libc++项目的方式；
• 使用 LLVM 工具包进行开发中的最佳实践，例如从一开始就使用清理程序和模糊测试。

活跃的 LLVM 开发人员之一 我有很明显，将 libc 作为 LLVM 工具包的一部分提供是有意义的，但通常，当出现这种需要时，他们会使用 musl 库，该库编写得很好，支持各种体系结构，并提供必要的功能，包括对动态的支持链接。 将 musl 嵌入到 LLVM 中并将其开发为与主项目同步的分支可能是合理的。

你的意见也 他表示， Musl 项目的作者试图论证为什么 Google 的提议以及将 Libc 纳入 LLVM 发行版是非常糟糕的想法：

• 开发和维护一个正确的、兼容的、高质量的Libc是一项非常艰巨的任务。 问题不在于代码量，而在于确保正确的行为和实现接口的困难，考虑到用 C/C++ 编写的应用程序的巨大层，以及使用其运行时的其他语言的应用程序由 Libc. 不考虑细微差别的正面做法只会导致许多现有程序无法与 Libc 配合使用，但这样的项目将不会引起消费者的兴趣。
• 企业开发可能会毁掉 Libc，但会推动它得到广泛使用，从而导致需要添加 hack 来确保应用程序的兼容性。 在企业开源项目的支持下进行开发将会掩盖公司的需求和解决方案，从而损害社区的利益。 例如，如果您发现一个问题是由另一个程序中的错误引起的，那么在受控开发中，确保 Libc 与此错误兼容比修复错误本身更容易。 Apple 使用 BSD libc 分支来实现这些目的，而 Google 在 Fuchsia 中使用 musl 分支。 musl 开发人员的经验是，主要由律师联系他以澄清许可问题，但在对其分支机构进行无用且具有破坏性的更改之前从未联系过他以澄清技术细节。
• libc 开发中不存在单一文化，并且注重共识驱动的标准而不是个人控制，这促使应用程序开发人员使用标准而不是受特定实现的束缚。 这就是为什么 musl 的作者反对将他的库包含在 LLVM 中，也反对在 LLVM 中开发 libc，因为在这种情况下，libc 的独立性就会丢失，某种实现会成为一流的解决方案。 LLVM 和所有其他解决方案都成为二流解决方案。

来源： opennet.ru