252

So I was surfing the net and stumbled upon this article. It basically states that FreeBSD, starting from Version 10 and above will deprecate GCC in favor of Clang/LLVM.

From what I have seen around the net so far, Clang/LLVM is a fairly ambitious project, but in terms of reliability it can not match GCC.

Are there any technical reasons FreeBSD are choosing LLVM as their compiler infrastructure, or does the whole matter boil down to the eternal GNU/GPL vs. BSD licenses?

This question has (somehow) relevant information about the usage of GCC in FreeBSD

Improve this question

4 Answers 4

Reset to default
372

Summary: The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project. There are also political issues to do with corporate investment, as well as user base requirements. Finally, there are expected technical advantages to do with standards compliance and ease of debugging. Real world performance improvements in compilation and execution are code-specific and debatable; cases can be made for both compilers.

FreeBSD and the GPL: FreeBSD has an uneasy relationship with the GPL. BSD-license advocates believe that truly free software has no usage restrictions. GPL advocates believe that restrictions are necessary in order to protect software freedom, and specifically that the ability to create non-free software from free software is an unjust form of power rather than a freedom. The FreeBSD project, where possible, tries to avoid the use of the GPL:

Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed FreeBSD license whenever possible.

FreeBSD and the GPL v3: The GPL v3 explicitly forbids the so-called Tivoisation of code, a loophole in the GPL v2 which enabled hardware restrictions to disallow otherwise legal software modifications by users. Closing this loophole was an unacceptable step for many in the FreeBSD community:

Appliance vendors in particular have the most to lose if the large body of software currently licensed under GPLv2 today migrates to the new license. They will no longer have the freedom to use GPLv3 software and restrict modification of the software installed on their hardware... In short, there is a large base of OpenSource consumers that are suddenly very interested in understanding alternatives to GPL licensed software.

Because of GCC's move to the GPL v3, FreeBSD was forced to remain using GCC 4.2.1 (GPL v2), which was released way back in 2007, and is now significantly outdated. The fact that FreeBSD did not move to use more modern versions of GCC, even with the additional maintenance headaches of running an old compiler and backporting fixes, gives some idea of the strength of the requirement to avoid the GPL v3. The C compiler is a major component of the FreeBSD base, and "one of the (tentative) goals for FreeBSD 10 is a GPL-free base system".

Corporate investment: Like many major open source projects, FreeBSD receives funding and development work from corporations. Although the extent to which FreeBSD is funded or given development by Apple is not easily discoverable, there is considerable overlap because Apple's Darwin OS makes use of substantial BSD-originated kernel code. Additionally, Clang itself was originally an in-house Apple project, before being open-sourced in 2007. Since corporate resources are a key enabler of the FreeBSD project, meeting sponsor needs is probably a significant real-world driver.

Userbase: FreeBSD is an attractive open source option for many companies, because the licensing is simple, unrestrictive and unlikely to lead to lawsuits. With the arrival of GPL v3 and the new anti-Tivoisation provisions, it has been suggested that there is an accelerating, vendor-driven trend towards more permissive licenses. Since FreeBSD's perceived advantage to commercial entities lies in its permissive license, there is increasing pressure from the corporate user base to move away from GCC, and the GPL in general.

Issues with GCC: Apart from the license, using GCC has some perceived issues. GCC is not fully-standards compliant, and has many extensions not found in ISO standard C. At over 3 million lines of code, it is also "one of the most complex and free/open source software projects". This complexity makes distro-level code modification a challenging task.

Technical advantages: Clang does have some technical advantages compared to GCC. Most notable are much more informative error messages and an explicitly designed API for IDEs, refactoring and source code analysis tools. Although the Clang website presents plots indicating much more efficient compilation and memory usage, real world results are quite variable, and broadly in line with GCC performance. In general, Clang-produced binaries run more slowly than the equivalent GCC binaries:

While using LLVM is faster at building code than GCC... in most instances the GCC 4.5 built binaries had performed better than LLVM-GCC or Clang... in the rest of the tests the performance was either close to that of GCC or well behind. In some tests, the performance of the Clang generated binaries was simply awful.

Conclusion: It's highly unlikely that compilation efficiency would be a significant motivator to take the substantial risk of moving a large project like FreeBSD to an entirely new compiler toolchain, particularly when binary performance is lacking. However, the situation was not really tenable. Given a choice between 1) running an out-of-date GCC, 2) Moving to a modern GCC and being forced to use a license incompatible with the goals of the project or 3) moving to a stable BSD-licensed compiler, the decision was probably inevitable. Bear in mind that this only applies to the base system, and support from the distribution; nothing prevents a user from installing and using a modern GCC on their FreeBSD box themselves.

Improve this answer
6
  • 4
    The benchmark you cited is from an old version of Clang. The benchmarks for recent versions seem to be recent versions are closer. My own research for simple programs put Clang 3.0 a couple of percent faster than GCC 4.6, but GCC was 20% faster on the threaded version. phoronix.com/scan.php?page=news_item&px=MTA5Nzc is a newer Phoronix benchmark.
    – Sean
    Nov 7, 2012 at 21:14
  • 7
    "GCC is not fully-standards compliant": Isn't it possible to use compiler switches to enforce compliance to a given standard?
    – Giorgio
    Jan 28, 2013 at 15:21
  • 6
    First of all don't read too much into Phoronix benchmarks, or rather don't read them at all. Second, it's true that GCC is not fully standards compliant by default unless you explicitly specify a standard, if you don't it will have the GNU extensions enabled too, but this would seem like an odd reason to use Clang instead, though, since they too are implementing the most commonly used GNU extensions because they strive for Clang being usable as a drop in replacement for GCC.
    – remmy
    Jun 18, 2013 at 19:21
  • 1
    @Giorgio: No. See gcc.gnu.org/c99status.html for an example -- and that's just C99 (which itself is 14 years old now). Also gcc.gnu.org/onlinedocs/libstdc++/manual/status.html -- clang has better support for both (I think it's full -- and if not, it's definitely at least better).
    – Tim Čas
    Aug 15, 2013 at 17:19
  • 4
    @Demizey I'm not defending Phoronix, but if you are going to dismiss something you should at least provide a valid reason.
    – Mario
    Feb 20, 2014 at 6:29
39

One thing worth considering is that FreeBSD is currently using GCC 4.2.1 as noted in ire_and_curses answer thus the performance comparisons aren't of 4.5 or even 4.6 aren't truly relevant to the project. Therefore, the questions you should be asking are:

  1. What are the performance gains of the new Clang vs the older GCC that the project uses?

  2. How do the same binaries compiled in GCC 4.2.1 compare to the new Clang?

Because of GCC's move to the GPL v3, FreeBSD was forced to remain using GCC 4.2.1 (GPL v2), which was released way back in 2007, and is now significantly outdated.

If Clang lags behind the current GCC but is still light years ahead of the implemented GCC in the project then their decision to evolve is well warranted and truly inspired.

Improve this answer
0
21

Even though GCC is GPLv3, the resulting binaries produced by GCC never had any license constraint. In clear you can use GCC to build software that falls under the license you want. Even the C library that comes with GCC and that is included in the binary is license-free. http://www.gnu.org/licenses/gcc-exception-faq.html

Section 2 of the GNU GPLv3:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

“Eligible” means that the compilation does not involve both GCC and GPL-incompatible software. That's not a restriction: BSD-licensed software can be used in the build process involving GNU GCC.

As you can see, contrary to what has been said above, there is no REAL license-related reason to move away from GCC as there is no incompatibility with using GCC inside FreeBSD.

The real reason behind this change is political and opportunistic:

  • BSD has its own licensing which philosophically competes with the GNU Public license (as *ire_and_curses* explained above),
  • CLANG is a new non-GPL compiler initiated by a sponsor of FreeBSD that appears to be technically equivalent to the GPL-licensed GCC (as described above by *ire_and_curses*).

These facts creates an opportunity for FreeBSD to move away from GCC and get rid of it: they're not actually legally compelled to, as they could well still use GCC to build free or BSD-licensed software, but they want to stick to the "all BSD licensed software" philosophy.

Improve this answer
6
  • 6
    Sorry I had to vote this down. Unfortunately your unfamiliarity with BSDs and software lows shows. Just for the record it was political not technical decision that lead BSDs from switching from its traditional Portable C Compiler (PCC) to GCC in early nineties. Clang is Apple project! As somebody who uses GCC on daily base for living on OpenBSD which is trying to move back to PCC you are just wrong in all accounts.
    – Predrag Punosevac
    May 21, 2013 at 4:20
  • 7
    It is not about the resulting binaries, it is about the fact that gcc is part of FreeBSD - therefore the license constraints do matter.
    – sstn
    Aug 24, 2013 at 13:26
  • 3
    If the religion of the project says "No GPLv3" then the technical aspects fade away - just imagine that they were using for instance a Microsoft compiler.
    – Thorbjørn Ravn Andersen
    Sep 11, 2013 at 19:44
  • 5
    This is the only answer that points out correctly that license of compiler != license of end product. Complaints about a license of the compiler can't possibly be relevant unless the user doesn't understand the license.
    – Brandin
    Sep 6, 2014 at 8:42
  • 8
    It's not about whether the binaries produced fall under GPLv3, it's whether changes to the compiler itself require GPLv3 compliance. Hardware vendors often modify the stock compiler to work with their hardware better or take advantage of hardware in proprietary ways. Removing the risk that your custom changes must comply with GPLv3 or risk legal action is a big deal for such organizations. It really is the license of the compiler that matters here.
    – David Harks
    Oct 19, 2014 at 12:46
8

I'm no expert, but my understanding is Clang/LLVM uses fewer resources than GCC and is quicker.

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

If you're running an environment where you need to build a lot of stuff, a lot of times, that performance may turn into real savings in energy costs and time. If it's real.

Improve this answer
3
  • Minor.. and there's tools to reduce repetitive compile times further - ccache.samba.org Never mind the obvious possibilities for parrallel compilation (see distcc), link times tend to be harder to solve in large projects
    – Rob11311
    Jul 6, 2014 at 16:17
  • 1
    Yes, very good, but the resulting binary code is slower ;p
    – rustyx
    Jul 17, 2014 at 12:22
  • 1
    @rustyx not compared to gcc 4.2!
    – Miles Rout
    May 31, 2016 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .