That was a long time ago and the actual primary reason was apparently Stallman missed an email [1], although I think the intentional technical hurdles to plugins was another of many reasons. When GNU moved all their software to GPLv3 and the business community decided they didn’t like that license and Apple brought LLVM as a serious contender.

GCC hasn’t remained stagnant though.

[1] https://lwn.net/Articles/632062/

Thanks for the article, I am not sure I fully understand it. Could you point to the section about the missed email? Also, do I understand it right, that emacs doesnt integrate well with llvm? (maybe that explains why in llvm presentations ppl use the 'other' editor, I always wondered why not use emacs)

> An interesting side note to the debate emerged when Liang Wang posted about LLVM creator Chris Lattner's offer to try to get LLVM's copyright assigned to the FSF back in 2005. It was part of an effort (that seemingly went nowhere) to integrate LLVM and GCC. Stallman never heard about the message:

So basically, if Stallman hadn't have missed the message, there's a very real possibility that LLVM would have ended up licensed under GPLv2 & then re-licensed to GPLv3. The engineering world would probably look radically different if that had happened.

That was ions ago, and if not for anything else, Linux kernel will keep GCC around.

Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.

There is significant investment in building Linux with Clang so I wouldn't count on Linux keeping GCC relevant forever. Doubly so with the inevitable rustc requirement.

Isn't that the other way around? I thought clang was trying to support all gcc extensions to be able to build Linux kernel.

I would rather see both of these compilers to stay competitive to push themselves higher.

Kind of both. They've added some gcc-specific extensions to clang, but also removed some gcc-ism's from the Linux kernel.

clang already builds Linux kernel on Mountain View dungeons, and it has been doing that for a couple of years now.

Those changes just don't get to upstream.

That's...not true?

https://www.kernel.org/doc/html/latest/kbuild/llvm.html

I could be missing something, but I don't see any suggestion that you need a specific forked tree with patches to build with LLVM, and I've seen people filing bugs about using LLVM sanitizers to build the vanilla tree, so I don't think the expectation is that you need to apply a huge out of tree patchset for this to work any more?

There's an semi-official github[0] for this.

AFAICT from the issues page, Clang and binutils/LLVM tools work fine with no patches for the mainstream archs and when not trying to be super-fancy with custom flags. The more non-mainstream one goes with arch or flags the more likely one will run into something.

[0] https://github.com/ClangBuiltLinux/linux/issues (Note they use github for issues/wiki, not code, so no surprise the 'linux version' in code is oldish).

I follow Android, not Linux itself.

My latest update was that not all patches were accepted upstream, or Google didn't care about upstreaming them, whatever.

There are some Linux Plumbers talks, or from Linaro, about this a years back.

The ongoing efforts to add a Rust frontend to GCC prove otherwise.

No Rust in GCC? No play.

Unlike C/C++, there is one canonical rustc where the language is developed and GCC will likely always play catch up.

It doesn't matter, if only GCC gets to play with Linux kernel.

Rust is only following down the footsteps of D and Go.

Android Linux fork compiles with clang for ages now. Upstream doesn't want them.

Why would the Linux kernel keep GCC around?

I'm fairly confident the FSF would keep it alive for a long time, but I don't see why it would be necessarily be a priority for the Linux devs to keep GCC forever.

Linux kernel makes use of GCC C, not ISO C, also targets hardware that LLVM doesn't support.

Android Linux kernel fork actually builds with clang, and Linux kernel is yet to accept the changes made by Google.