摘要: 从GCC 迁移到 Clang 的主要原因是GCC 的GPL v3与 FreeBSD 项目目标的不兼容. 还有一些与公司投资相关的政治因素，以及来自用户的需求. 当然, 也有一些技术上的因素, 如符合标准, 容易调试. 但对于实际编译和运行性能的提升任具有争议且依赖于具体的代码, 两个编译器各有所长.
翻译于 2013/08/14 15:59
FreeBSD 为什么要废弃 GCC 改用 Clang/LLVM？ 已翻译 100%
加载中
FreeBSD 和 GPL v3协议:GPL v3很明确的禁用了代码的所谓Tivoisation认证，在GPL v2协议中，存在一个可以通过硬件限制来阻止用户对软件程序进行合法修改的漏洞。怎么样很好的关闭这个漏洞是FreeBSD社区并不期望的步骤。
在v2协议中由于臃肿的软件认证而受损的设备商如今正在向新的认证迁移。他们不再具有使用v3软件同时修改安装到本地硬件平台的自由...简短来说，将会有一大批热爱开源社区的人们突然对CPL新的认证软件的可选性变得饶有兴趣
翻译于 2013/08/15 09:04
因为GCC已经转移到GPL v3 (通用公共许可证General public license)，FreeBSD被迫继续使用GCC 4.2.1 (GPL v2)，它还是
早在2007年发布
的 ，现在已经明显过时。现实是FreeBSD没有转而使用GCC的更为现代的版本，即使是存在运行老旧编译器与(从新版本)向后移植修复之类的额外困难，所以应当考虑一下对避免GPL v3的必要性的强调。C编译器是FreeBSD基石的一个主要组件，而且是"
将FreeBSD 10作为基于GPL免费系统的 (试验性的)目标之一"。
翻译于 2013/08/15 19:22
用户基础：FreeBSD对许多公司来说是一个诱人的开源选项，因为她的许可是简单的，低限制以及不会引导公司走向诉讼的许可。随着GPL v3以及 反 Tivoisation时代的到来，越来越多的迹象显示，未来将会 是迅速的，以设备商为驱动的多元化许可时代。随着FreeBSD逐渐觉察到了那些建立在自己许可之上的商业实体所能带来的巨大利益，对于那些要从GCC以及传统GPL迁移许可方式的合作伙伴来说，他们的将会面临越来越大的压力。
GCC存在的问题：除了许可部分，在使用GCC的过程中 还存在许多比较明显的问题。GCC并没有完全符合已制定规范标准，他的 许多扩展在ISO以及C标准规范中并没有定义。在超过300万行之多的代码中，他仅仅是“ 一个复杂的免费开源软件项目”。其复杂性使得他在发行版发行后再进行修改变成巨大的挑战
翻译于 2013/08/16 08:58
技术性的优势：
Clang与GCC相比拥有许多技术上面的优势。其显著特点在于
数量众多的错误信息提示以及一个
定义良好的IDE接口。同时他又支持代码重构并且提供代码分析工具。尽管
Clang官网上提出了更有效的编译以及内存管理功能。但是实际
情况却是不同的。GCC在代码方面的表现还是比较优秀的。总之，Clang提供的二进制库比GCC
运行速度更慢。
虽然使用LLVM在构建代码的时候比GCC更加迅速...但是在大多数情况下，GCC4.5的二进制类库的变现是好于LLVM-GCC和Clang...在其他的一些测试中，其表现则是接近或者是远远落后。在大多数测试中，Clang的整体二进制库是非常简单的。
翻译于 2013/08/16 09:20
总结 ：这样强有力的编译器并不是一次冒险将一个像FreeBDS这样的大项目改变成一个新的编译器工具链的重要激励。尤其是在二进制运行效果不佳的情况下。然而，这种情况在现实中却是站不住脚的。让你在以下几种情况中做一个选择
1）继续使用过时的GCC，
2）迁移到最新版GCC并被迫使用一个与项目目标不适应的许可，或者
3）干脆迁移到一个支持BSD许可的稳定编译器，这样的选择在现实中似乎是不可避免的。
需要清楚的是：这些情况只应用在基础系统中，并且服务于系统发布；至于其他情况，没有其他任何事情都不能阻止用户在基于FreeBSD的项目中安装和使用一个现代版的GCC
翻译于 2013/08/16 18:31
加载中
删除一条评论
评论删除后，数据将无法恢复
深圳市奥思网络科技有限公司版权所有
粤ICP备12009483号
评论(31)
我觉得，开源不代表免费，免费也不等于开源，过分地强调自由，认为是不合理的。我喜欢BSD协议，不支持gpl，当然，想不用到也是很难的……
GCC不但是C/C++/ObjC 编译器，而且还要能编译Ada, Fortran, Java, Pascal编译器，前端代码并不是人编写的C程序，而是用被称为“词法分析器”和“语法分析器”的Flex， Bosion生成的C程序。麻烦来了，生成的代码谁都看不懂，也没有人敢对这部分代码修改完善hack。同样的情况也出项GNU AutoMake生成的那一个超长的Configre文件。
我不知道为什么用Flex和Bosion生成这部分代码，是因为编写能编译多种源程序的程序工作量大？ 有难度? 又或者只是因为他们之中有人会用Flex和Bosion， 而且生成的程序工作良好，所以没必要人工写词法语法分析？ 总之，GCC与Flex和Bosion就这样紧密的绑在一起了，似乎这种情况还会持续十年以上甚至更久。
软件发展变化更新太快，很多软件都是一年一个版本，同样类型的软件甚至有个几十个“竞争对手”，可惜这种情况并没有出现在词法分析器、语法分析器上，自从这两个程序发明以来，几乎就没有动过，没有哪个人冒出来说：“嘿，这两程序语法规则的编写已经不符合编程语言的变化，我有个新的想法.....”，或者说：“这两程序生成的程序太糟糕”..等等
这样的前端是我不能忍受的，我相信也是苹果、Bsd社区不能接受的，我们当中的大部分程序员没见过Ada, Fortan程序，不需要他们，至于Java, Pascal，虽然我们也从各种渠道学过，不过这三并不是我们所喜爱的东西，我们只需要C/C++/Obj C，因为我们需要一个新的前端Clang。
引用来自“ak_birdofprey”的评论
GPLV3给了所有人一种终极自由。但有人想把它据为己有是不可能的。从这个观点出发，GPLV3给了软件世界一个自由市场的模式。社区的存在让探索得以不断发展，而企业也同时可以为大家提供更好的产品。尽管有时山寨会一时蒙蔽大家，但随着时间的推移我想很多人还是会抛弃山寨的，比如ORACLE所谓的铁甲LINUX，最终我用过之后还是觉得直接用REDHAT的会更有安全感！！！
引用来自“沙枣”的评论
就好像苹果和微软，本就是靠模仿和跟随，加上自己的努力成长。成为巨人后，却成为阻碍别人模仿和跟随的一块绊脚石。
引用来自“GNU/数据”的评论
本文有点像是谷歌翻译的。。。太生硬了