By Nathan Willis
January 29, 2014
GCC, the GNU Compiler Collection, is a cornerstone of the GNU project and the larger free-software community that has grown up around it. Recently a debate
sprang up on the GCC mailing list over the question of whether GCC ought to deliberately adopt a development approach more like that of rival compiler LLVM. Precisely
which aspects of LLVM's approach were desirable for adoption depends on who one asked, but the main argument was that LLVM seems to be attracting more users. The GCC project, however, contends that LLVM's perceived popularity is due largely to its accommodation
of proprietary extensions—which is something that GCC supporters consider decidedly contrary to their core objectives.
Few would consider it a stretch to say that GCC has grown to dominate the compiler landscape over the course of its 26-plus years as a project, to the point where its popularity extends beyond free-software circles, and it is even routinely used to compile
proprietary code—a scenario that is ripe for bringing interests other than software freedom into development discussions. In recent years, though, newer compiler projects have made names for themselves, LLVM being the most famous at present.
LLVM started off as a research project at the University of Illinois at Urbana–Champaign; befitting the needs of researchers, it has been developed in a modular form that allows easy replacement of individual components: front ends, code generators, optimizers,
and so on. It was also released under the University of Illinois Open Source License, which is a permissive, BSD-style license
that requires copyright attribution but permits the code to be used in proprietary applications. And indeed there are multiple proprietary compilers and utilities built on top of LLVM—including Apple's Xcode and NVIDIA's CUDA compiler.
For whom the bell clangs
The present debate was touched off by a comment from Dmitry Gutov on the emacs-devel list on January 19. In the midst of a discussion about Emacs's company-modeauto-completion
framework (specifically, a minor mode designed to work with the LLVM front end Clang), Gutov said that he had heard Richard Stallman disliked Clang so much that he would oppose importing any code from it into Emacs. That spawned a lengthy thread about Clang/LLVM
and GCC's differing approaches to software freedom—in particular, about the merits of copyleft licensing.
The various sides of that debate have all been argued many times in the past, of course, and this incarnation of the topic did not break any real new ground. Stallman's position, in short, is that Emacs and other official GNU applications should not incorporate
default features designed to work with non-GNU projects (like LLVM) that do not work with the corresponding GNU project (GCC).
The debate was revived on January 21, however, when Eric S. Raymond contended that the very existence of Clang/LLVM was a response to the GCC project's
resistance to broad interoperability. The Clang developers, he said, "want to build IDEs and other tools that share the compiler's code. GCC policy won't let them do that. Ergo, GCC must be kicked aside." Raymond also
argued that LLVM bests GCC on several technical measures, a claim that was rapidly met with disagreement and, for the most part, dropped.
But the original point remained the subject of the resulting list thread (and several overlapping threads, some of which were cross-posted to the GCC development list). Essentially, Raymond argued that LLVM's modularity is a strong selling point among users
that GCC cannot match. Whatever one thinks of the relative quality of LLVM and GCC, LLVM is clearly a capable enough compiler that GCC should be worried about losing market share (so to speak) to it among users. The solution, Raymond said,
was for GCC developers to abandon their monolithic architecture and adopt a modular compiler design like LLVM's.
The mod squad
Modularity, though, is not a simple design question where compilers are concerned. As several in the discussion pointed out, it is actually LLVM's modularity combined with its non-copyleft license that makes it attractive to many proprietary software companies.
Apple, NVIDIA, and other downstream LLVM users build their proprietary IDEs on LLVM—at least partly—because they do not want to be bound by the GPL's copyleft requirements. As David Edelsohn said,
"The issue for companies is control: which compiler allows them better access / control over the toolchain control point of the ecosystem and which allows them to create a walled garden to improve their margins and their business
model."
In essence, asking GCC to be "more like LLVM" is not a matter of modularity alone, but of making it possible to use GCC with proprietary add-ons or extensions. And although (as Joseph Myers pointed
out) GCC is more modular than it used to be (with more such refactoring work on the to-do list), GCC's developers have actively resisted allowing
it to be modularized in a way that would allow GCC's internal representation of a program to be read and used by proprietary compilation tools or optimizers. Stallman even reiterated this
point in the current thread. GCC's present plugin system debuted with GCC 4.5.0 in 2010, but the project was keen to ensure that it does not offer
a "black box" API to its internal representation.
Still, it has never been possible to fully prevent others from hacking together their own plugins, which in turn has led to some unusual licensing moves by the project. Early on, the GCC team made the decision that GCC should be able to compile
proprietary code (a choice which was certainly not a given, since that could be construed as "promoting" proprietary software). The question came up due to the different nature of compilers when compared to "regular" programs. Certainly nothing in the GPL
itself prevents using GPL-licensed software to work on proprietary software.
But GCC adds its own runtime library to the object code that it produces, which creates the first dilemma. Strictly speaking, this linking of the GCC runtime library would make any program compiled by GCC a derivative of GCC, which in turn means
it would inherit GCC's GPL license. The solution to that problem was the GCC Runtime Library Exception, which explicitly exempts
this situation and allows GCC-compiled programs to be released under whatever license the program authors would otherwise choose.
In 2009, the GCC project released an updated version of the exception designed to specifically address the second problem—what to do about proprietary
GCC plugins. The exception discourages them by explicitly allowing user to distribute a GCC-generated binary under a proprietary license only if no proprietary plugins were used to compile the binary.
Thus, the GCC Runtime Library Exception leverages the GPL to discourage the use of GCC in conjunction with proprietary add-ons. But there are not that many GCC plugins to begin with, since (as Ian Lance Taylor explained),
the plugin interface "simply exposes GCC internals, and as such is not stable across releases." Others have argued that the unstable interface acts like an effective deterrent to those attempting to maintain out-of-tree
patch sets as well, though it has the unfortunate side effect of making it difficult to write free GCC plugins, too.
Fight club
Whatever one thinks about the peculiar requirements that the runtime library exception sets up, it is undeniable that the GCC team is not interested in supporting the permissive approach taken by LLVM. Stallman made this point when he replied that
allowing non-free plugins "would be throwing in the towel. If that enables GCC to 'win', the victory would be hollow, because it would not be a victory for what really matters: users' freedom."
Then again, there is considerable disagreement over what "winning" really means for GCC, and even over whether LLVM and other compilers are in a competition with GCC. Raymond and others pushing for a more LLVM-like approach argue that LLVM will attract more
users than GCC. That is certainly a simple metric, but to many it is not a relevant one. Jonathan Wakely commented that Raymond thinks he is "helping
us win a war with Clang. But there is no war. There's room for two high-quality open source compilers. They will distinguish themselves in different ways, one of which is licensing."
Perhaps the more extreme viewpoint would be that GCC faces an existential threat from LLVM. Along those lines was Daniel Colascione's comment that
"Free software is great, but if nobody uses it, the entire enterprise is futile, sad, and ultimately irrelevant." To that, Stallman responded,
"Free software is equally futile, sad, and irrelevant if everyone uses it...as a base for nonfree software."
Ultimately, all parties to the debate said that they are interested in seeing the number of GCC users increase. The root of the "competition" disagreement tended to come down to whether the GCC team's plugin policy amounts a barrier to attracting new users.
Helmut Eller called it a "policy of introducing artificial technical hurdles to prevent some nonfree programs"
and caused collateral damage. David Kastrup replied that "the whole point of the GPL is to introduce an 'artificial
hurdle' preventing turning code into proprietary programs," and, significantly, it is a hurdle that works, as the absence on proprietary compilers built on top of GCC demonstrates.
There will likely always be people for whom the proprietary derivatives of a permissively-licensed program like LLVM are a problem, and there will be others who do not care about them, so long as free software exists, too. Similarly, to some people, if LLVM
attracts more users than GCC, it must reveal that GCC is flawed, while to others the relative numbers are meaningless.
On the more concrete questions, however, the answers are considerably less nebulous. Stallman and the GCC team have made their position clear about adopting a lax attitude toward proprietary plugins in GCC: it is a non-starter. Whether that stance amounts
to a fundamental flaw in GCC itself depends on the individual—but do not expect GCC to change its tune simply because LLVM has attracted its own crowd of users.
(
Log in to post comments)
