Nli*_*tis 248 freebsd compiling c gcc llvm
所以我在网上冲浪，偶然发现了这篇文章。它基本上表明FreeBSD从版本 10 及更高版本开始将弃用GCC以支持Clang/LLVM。
从我目前在网上看到的情况来看，Clang/LLVM是一个相当雄心勃勃的项目，但在可靠性方面它无法与GCC 相提并论。
FreeBSD 选择 LLVM 作为他们的编译器基础设施是否有任何技术原因，或者整个问题归结为永恒的 GNU/GPL 与 BSD 许可证？
ire*_*ses 369
总结： 从GCC切换到Clang 的主要原因是 GCC 的GPL v3许可证与FreeBSD 项目的目标不兼容。还有与企业投资以及用户群要求有关的政治问题。最后，预期的技术优势与符合标准和易于调试有关。编译和执行方面的实际性能改进是特定于代码的且有争议的；可以为两个编译器制作案例。
FreeBSD 和 GPL： FreeBSD与 GPL 之间的关系并不融洽。BSD 许可证倡导者相信真正的自由软件没有使用限制。GPL 倡导者认为限制是必要的，以保护软件自由，特别是从自由软件创建非自由软件的能力是一种不公正的权力形式，而不是自由。在可能的情况下，FreeBSD 项目试图避免使用 GPL：
由于 GPL 软件的商业使用可能会带来额外的复杂性，但是，我们确实尽可能用更宽松的 FreeBSD 许可下的提交来替换此类软件。
FreeBSD和在GPL v3的：在GPL v3中明确禁止所谓Tivoisation的代码，在一个漏洞GPL v2协议，这使硬件限制用户以禁止，否则法律修改软件。对于 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从企业那里获得资金和开发工作。尽管 Apple 资助或给予 FreeBSD 开发的程度并不容易发现，但存在相当大的重叠，因为 Apple 的Darwin OS使用了大量源自 BSD 的内核代码。此外，在 2007 年开源之前，Clang 本身最初是一个内部 Apple 项目。由于企业资源是 FreeBSD 项目的关键推动者，满足赞助商的需求可能是一个重要的现实世界驱动力。
用户群：对于许多公司来说，FreeBSD 是一个有吸引力的开源选项，因为许可简单、不受限制并且不太可能导致诉讼。随着 GPL v3 和新的反 Tivoisation 条款的到来，有人提出了一个加速的、供应商驱动的趋向于更宽松的许可证的趋势。由于 FreeBSD 对商业实体的明显优势在于其宽松的许可证，因此来自企业用户群的压力越来越大，要求远离 GCC 和 GPL。
GCC 的问题：除了许可证之外，使用 GCC 还存在一些明显的问题。GCC 不完全符合标准，并且有许多 ISO 标准 C 中没有的扩展。超过 300 万行代码，它也是“最复杂、最自由/开源的软件项目之一”。这种复杂性使发行版级别的代码修改成为一项具有挑战性的任务。
技术优势：与 GCC 相比， Clang 确实具有一些技术优势。最值得注意的是提供更多信息的错误消息和为 IDE、重构和源代码分析工具明确设计的 API。尽管 Clang 网站提供了表明编译和内存使用效率更高的图，但现实世界的结果差异很大，并且与 GCC 性能大致相符。通常，Clang 生成的二进制文件比等效的 GCC 二进制文件运行得更慢：
虽然使用 LLVM 在构建代码方面比 GCC 更快……在大多数情况下，GCC 4.5 构建的二进制文件比 LLVM-GCC 或 Clang 表现得更好……在其余测试中，性能要么接近 GCC 要么很好在后面。在某些测试中，Clang 生成的二进制文件的性能非常糟糕。
结论：编译效率极不可能成为承担将像 FreeBSD 这样的大型项目转移到全新编译器工具链的重大风险的重要动机，尤其是在缺乏二进制性能的情况下。然而，这种情况并没有真正站得住脚。如果可以选择 1) 运行过时的 GCC，2) 迁移到现代 GCC 并被迫使用与项目目标不兼容的许可证，或者 3) 迁移到稳定的 BSD 许可编译器，则决定大概是不可避免的。请记住，这仅适用于基础系统和发行版的支持；没有什么能阻止用户自己在他们的 FreeBSD 机器上安装和使用现代 GCC。
小智 39
值得考虑的一件事是，如ire_and_curses 回答中所述，FreeBSD 目前正在使用 GCC 4.2.1，因此性能比较不是 4.5，甚至 4.6 与项目并不真正相关。因此，您应该问的问题是：
与项目使用的旧 GCC 相比，新 Clang 的性能提升是什么？
在 GCC 4.2.1 中编译的相同二进制文件与新的 Clang 相比如何？
由于 GCC 转向 GPL v3，FreeBSD 被迫继续使用 GCC 4.2.1 (GPL v2)，它早在 2007 年就发布了，现在已经明显过时了。
如果 Clang 落后于当前的 GCC，但仍比项目中实施的 GCC 领先数光年，那么他们做出发展的决定是有根据的，并且真正受到启发。
Eri*_*ric 21
尽管 GCC 是 GPLv3，但 GCC 生成的二进制文件从未有任何许可限制。很明显，您可以使用 GCC 来构建属于您想要的许可证的软件。甚至 GCC 附带并包含在二进制文件中的 C 库也是免许可的。http://www.gnu.org/licenses/gcc-exception-faq.html
GNU GPLv3 第 2 节：
您有权传播通过将运行时库与独立模块组合而形成的目标代码作品，即使这种传播会违反 GPLv3 的条款，前提是所有目标代码都是由合格编译过程生成的。然后，您可以根据您选择的条款传达这样的组合，与独立模块的许可一致。
“合格”意味着编译不涉及 GCC 和 GPL 不兼容的软件。这不是限制：可以在涉及 GNU GCC 的构建过程中使用 BSD 许可的软件。
正如您所看到的，与上面所说的相反，没有与许可证相关的真正原因要离开 GCC，因为在 FreeBSD 中使用 GCC 没有不兼容性。
这种变化背后的真正原因是政治和机会主义：
这些事实为 FreeBSD 提供了一个远离 GCC 并摆脱它的机会：他们实际上并没有被法律强制，因为他们仍然可以使用 GCC 来构建免费或 BSD 许可的软件，但他们想坚持“所有 BSD 许可软件”的理念。
我不是专家，但我的理解是 Clang/LLVM 使用的资源比 GCC 少，而且速度更快。
http://clang.llvm.org/features.html#performance
如果您运行的环境需要多次构建很多东西，那么这种性能可能会真正节省能源成本和时间。如果是真的。