为什么 FreeBSD 弃用 GCC 而支持 Clang/LLVM?

为什么 FreeBSD 弃用 GCC 而支持 Clang/LLVM?

所以我在网上冲浪时偶然发现本文。它基本上表明自由BSD,从版本10及以上开始将弃用海湾合作委员会有利于铿锵/LLVM

从目前我在网上看到的情况来看,铿锵/LLVM是一个相当雄心勃勃的项目,但就可靠性而言,它无法匹敌海湾合作委员会

有没有技术的FreeBSD 选择 LLVM 作为其编译器基础设施的原因,或者整个问题是否归结为永恒的 GNU/GPL 与 BSD 许可证?

这个问题(以某种方式)有关于使用的相关信息海湾合作委员会自由BSD

答案1

概括: 从以下位置切换的主要原因海湾合作委员会是GCC的不兼容通用公共许可证 v3许可证与FreeBSD 项目的目标。还有与企业投资以及用户群要求有关的政治问题。最后,在符合标准和易于调试方面具有预期的技术优势。现实世界中编译和执行方面的性能改进是特定于代码的并且是有争议的;可以为两个编译器制作案例。

FreeBSD 和 GPL: 自由BSD与 GPL 的关系不太好。 BSD 许可证倡导者相信真正的自由软件无使用限制。 GPL 倡导者认为限制是必要的为了保护软件自由,特别是从自由软件创建非自由软件的能力是一种不公正的权力形式而不是一种自由。 FreeBSD 项目尽可能地尝试避免使用 GPL:

然而,由于 GPL 软件的商业使用可能会产生额外的复杂性,因此我们会尽可能使用更宽松的 FreeBSD 许可证下的提交来替换此类软件。

FreeBSD 和 GPL v3:通用公共许可证 v3明确禁止所谓的蒂沃化代码中的一个漏洞GPL 版本这使得硬件限制不允许用户进行其他合法的软件修改。堵住这个漏洞是一个不可接受的步骤对于 FreeBSD 社区的许多人来说:

如果当前根据 GPLv2 授权的大量软件迁移到新许可证,设备供应商的损失尤其最大。他们将不再有使用 GPLv3 软件的自由,并限制对其硬件上安装的软件的修改……简而言之,有大量的开源消费者突然对了解 GPL 许可软件的替代品非常感兴趣。

由于 GCC 转向 GPL v3,FreeBSD 被迫继续使用 GCC 4.2.1(GPL v2),这是早在 2007 年就发布了,现在已经明显过时了。事实上,FreeBSD 没有转向使用更现代版本的 GCC,即使运行旧编译器和向后移植修复程序带来了额外的维护麻烦,这一事实让人们了解了避免 GPL v3 的要求的强度。 C 编译器是 FreeBSD 基础的主要组件,并且“FreeBSD 10 的(暂定)目标之一是实现无 GPL 的基础系统”。

企业投资:与许多主要的开源项目一样,FreeBSD 受到资金开发工作来自企业。尽管 FreeBSD 在多大程度上由 Apple 资助或开发并不容易发现,但存在相当大的重叠,因为 Apple达尔文操作系统使用大量源于 BSD 的内核代码。此外,Clang 本身最初是 Apple 的一个内部项目,然后才被2007年开源。由于企业资源是 FreeBSD 项目的关键推动者,因此满足赞助商的需求可能是现实世界的重要驱动因素

用户群:对于许多公司来说,FreeBSD 是一个有吸引力的开源选择,因为许可简单、不受限制并且不太可能导致诉讼。随着 GPL v3 和新协议的到来反 Tivoization 条款,有人建议有一个供应商驱动的趋势正在加速走向更宽松的许可证。由于 FreeBSD 对商业实体的优势在于其宽松的许可证,因此企业用户群要求放弃 GCC 和一般 GPL 的压力越来越大。

海湾合作委员会的问题:除了许可证之外,使用 GCC 还具有一些察觉到的问题。 GCC 并不完全符合标准,并且已ISO 标准 C 中未找到许多扩展。超过 300 万行代码,它也是“最复杂和免费/开源软件项目之一”。这种复杂性使得发行版级别的代码修改成为一项具有挑战性的任务。

技术优势:Clang 确实有一些与GCC相比的技术优势。最值得注意的是提供更多信息的错误消息明确设计的API用于 IDE、重构和源代码分析工具。虽然 Clang 网站呈现情节表明编译和内存使用效率更高,实际结果是变化很大,并且与 GCC 的性能大致一致。一般来说,Clang 生成的二进制文件跑得更慢比等效的 GCC 二进制文件:

虽然使用 LLVM 构建代码比 GCC 更快...在大多数情况下,GCC 4.5 构建的二进制文件的性能比 LLVM-GCC 或 Clang 更好...在其余测试中,性能要么接近 GCC,要么很好在后面。在某些测试中,Clang 生成的二进制文件的性能非常糟糕。

结论:编译效率不太可能成为冒着巨大风险将像 FreeBSD 这样的大型项目转移到全新的编译器工具链的重要动机,特别是在二进制性能缺乏的情况下。然而,这种情况并不能真正维持下去。考虑到以下选择:1) 运行过时的 GCC,2) 迁移到现代 GCC 并被迫使用与项目目标不兼容的许可证,或 3) 迁移到稳定的 BSD 许可编译器,该决定可能是不可避免的。请记住,这仅适用于基本系统以及发行版的支持;没有什么可以阻止用户在他们的 FreeBSD 机器上安装和使用现代 GCC。

答案2

值得考虑的一件事是 FreeBSD 目前使用 GCC 4.2.1 作为在 ire_and_curses 答案中注明因此,性能比较不是 4.5,甚至 4.6 与项目并不真正相关。因此,您应该问的问题是:

  1. 项目使用的新 Clang 与旧 GCC 相比有何性能提升?

  2. 在 GCC 4.2.1 中编译的相同二进制文件与新的 Clang 相比如何?

由于 GCC 转向 GPL v3,FreeBSD 被迫继续使用 GCC 4.2.1 (GPL v2),该版本早在 2007 年就发布了,现在已经明显过时了。

如果 Clang 落后于当前的 GCC,但仍比项目中实施的 GCC 领先数光年,那么他们的发展决定是有充分理由的,并且真正受到启发。

答案3

尽管 GCC 是 GPLv3,但 GCC 生成的二进制文件从来没有任何许可证限制。显然,您可以使用 GCC 来构建属于您想要的许可证的软件。即使是 GCC 附带且包含在二进制文件中的 C 库也是免许可的。http://www.gnu.org/licenses/gcc-exception-faq.html

GNU GPLv3 第 2 节:

您有权传播通过将运行时库与独立模块相结合而形成的目标代码作品,即使此类传播会违反 GPLv3 的条款,前提是所有目标代码均由合格的编译进程生成。然后你可以传达这样的组合根据您选择的条件,与独立模块的许可一致。

“合格”是指编译不涉及GCC和GPL不兼容的软件。这不是限制:BSD 许可的软件可以在涉及 GNU GCC 的构建过程中使用。

正如你所看到的,与上面所说的相反,没有真实的放弃 GCC 的许可相关原因,因为在 FreeBSD 中使用 GCC 没有不兼容性。

这一变化背后的真正原因是政治和机会主义的:

  • BSD 有自己的许可证,在哲学上与 GNU 公共许可证竞争(如上面 *ire_and_curses* 所解释的),
  • CLANG 是一种新的非 GPL 编译器,由 FreeBSD 的赞助商发起,在技术上似乎等同于 GPL 许可的 GCC(如上面 *ire_and_curses* 所描述的)。

这些事实为 FreeBSD 提供了远离 GCC 并摆脱它的机会:他们实际上并没有法律强制这样做,因为他们仍然可以使用 GCC 来构建免费或 BSD 许可的软件,但他们想坚持“所有BSD许可软件”的理念。

答案4

我不是专家,但我的理解是 Clang/LLVM 使用的资源比 GCC 少,而且速度更快。

http://clang.llvm.org/features.html#performance

如果您运行的环境需要多次构建大量内容,那么这种性能可能会真正节省能源成本和时间。如果是真的的话。

相关内容