I found the counter-argument made in the first reply to be more compelling. <a href="http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html</a><p>Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.
As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I <i>think</i> it is also a case of "we don't want the burden of maintaining an outdated, inferior ABI for the sake your proprietary crap -- share or GTFO (And it's easier for everyone if we can just see your code, bugs and all)").<p>However, isn't this paragraph:<p>"I also think it bears noticing that nobody outside of Microsoft seems
to particularly want to write proprietary compilers any more. GCC won
its war; the cost and time-to-market advantages of hooking into
open-source toolchains are now so widely understood that new processor
designs support them as a matter of course."<p>proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially) doing? I know Apple makes great contributions to (among other projects, clang) -- but is upstream clang the same as what comes with Xcode?
ESR is comming hard on FSF to what is actually embracing "open source" movement. His arguments are technical only as a means to hide the politics.<p>This is not going to happen. I think David Kastrup's reply was pretty clear in that sense.<p><a href="http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html</a>
Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools.<p>I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war?<p>edit: I'm now aware that esr is not talking about license restrictions but technical restrictions here. I have yet to find any evidence of technical restrictions for political reasons though, and it looks like the folks responding to him on the mailing list are not sure what he means either.
IMHO GCC has already lost this batle.
Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source.
This is just impossible with GCC.
GCC is just a compiler but Clang is much more as this is a very powerful compiler building library...
If we talk about C++ then Clang already support C++14 but GCC still not.
And yes License matters, GPL just does not allow to use GCC in most cases. But today one does not need GCC at all any more, there is Clang.
gcc-xml was a hope many years ago but it just died, and today all this can be made much much easier and faster using Clang.
Clang is standard on OSX.
Some Linux distributions already switching to the Clang.
Clang support for Windows is already on the way.<p>So if nothing will be changes in GCC politics then it will become unnecessary in the future.
Of course some will still use it but only as political reasons.
esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete with LLVM, it just needs to become a technically better product. I don't buy the implication that it cannot become that without dropping some of the FSF's goals.<p>The gcc project is ancient and while I don't know the code base well, I'd assume that the fact doesn't necessarily help make it more approachable for new developers. Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people? The licenses seem to allow it.
The idea that the FSF (and perhaps more specifically, RMS) are holding back GCC technically due to concerns about people working around the GPL dates way back. As people have pointed out, GCC now has a plugin system but I imagine ESR is thinking back to exchanges such as this one, where RMS rejected the contribution of a Java bytecode backend to GCC purely on the grounds that it could be used with proprietary tools using the bytecode as an IR <a href="http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html</a>
ESR may be incorrect; GCC has a plugin system. (YMMV)<p><a href="http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html</a> / <a href="http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html</a>
I wrote this six months ago:<p><i>If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary.</i> (<a href="https://news.ycombinator.com/item?id=6146066" rel="nofollow">https://news.ycombinator.com/item?id=6146066</a>)<p>This is still true, and <i>this</i> is the reason we cannot allow GCC to give up or declare “victory” and move on.
As I see it, the whole disagreement seems to stem from differing opinions about what happens when free/open software and non-free/closed software meet, and which is "stronger".<p>FSF lives on an island and worries that even one contaminated inhabitant will infect everybody. They seem to hold that non-free is a contagious disease that will overtake and destroy their freedom. FSF is worried about diminishing: what they have is perfect and it can only be reduced. FSF are Tolkein's Elves.<p>ESR would welcome contaminated people to that island, believing strongly in it's restorative properties. He seems to hold that open-source is more powerful and will stamp out closed software whenever they meet. ESR is worried about not expanding quickly enough and dying of stagnation. ESR would probably be Aragorn.<p>That's how I see this argument.
Sounds like this was posted without reading the linked thread. He retracted the post in a followup as he didn't know about the GCC plugin system: <a href="http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html" rel="nofollow">http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html</a>
I see GCC as performing the necessary function of defining the radical antithesis to proprietary tools, historically like Think C, C++, Borland,and Metrowerks, and presents tools like Microsoft's Visual C/C++.<p>Without GCC staking out the position it has clang wouldn't have its middle ground to stake out. The middle ground would instead be a lot more proprietary than it is now.<p>Without Stallman being as radical as he is, there would be no Linus' who bridge the gap between completely free and completely proprietary software. There would be nothing to react to.<p>Many wrongs actually do make a right, as long as we're all wrong in opposite directions.
I doubt ESR was genuinely interested in changing GCC policy - that seems to be like a well written piece of concern trolling. If you want to make suggestions, you discuss it politely with the stakeholders, you don't make intentionally provocative suggestions on a public mailing list.
"I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more."<p>Someone should tell Intel that. Don't they still do things to intentionally make AMD CPUs look bad?
<i>"The clang developers very carefully do _not_ say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals"</i><p>Beliefs don't need them, but I don't see a rational argument supporting that. IMO, clang developers just won't cripple their product to prevent the potential collateral damage to gcc.
Ugh, more free software vs. open source politics. In the interest of actually collaborating and getting shit done, I'd like "freedom" from all this nonsense please.