> EDIT: Next, I predict a linux distro will, after having switched to musl, also support llvm/compiler-rt/libunwind/libc++ as base toolchain instead of gcc/libgcc/libstdc++

You're probably right, but I hate that the work free software developers contribute to LLVM & clang will end up being taken proprietary by the likes of Apple. With GCC one knows that the users of one's code will always have the ability to run, read, modify & share that code, rather than having their rights stripped away.

Yes, some people won't give back. However, a project like llvm/clang, most people do give back because sharing is cool, and also it makes their job easier because they don't have to repatch for every new version of the compiler. Sony's team developing the Playstation 4 wished at times they could use newer versions of llvm/clang for their software, but couldn't because their version had so many patches [1]. Because of this, after the PS4 was released, Sony developers sent a bunch of patches upstream, and work pretty closely with the rest of the developers. Some bits and pieces may not get merged upstream, but that's the same for any project, GPL or not.

[1] http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain....

On the flip side, code from permissively-licensed projects (like LLVM/clang) can be incorporated into free software with GPL-incompatible licenses. I personally consider that gain to be more than worth the risk of proprietary forks.

Also, the licenses of neither GCC nor LLVM apply to programs compiled by either project. I don't think that's what you meant by the copyleft sentiment, but the wording of that bit is weird and it's worth clarifying just in case.

Please note that no company has the right to strip your copyright or license away. But they may chose to extend your software without giving you access to the extension, if that is permitted by the license.

"after having switched to Musl" - Musl is not GPL either.

The BSDs have been used in proprietary software, but the open source projects continue as the centre of development.

NetBSD has had two installs, one with the gcc chain and one with the llvm chain for some years now. unwind compatibility was a problem but is getting better I think. For the base distro it makes less difference perhaps, although more C++ code is coming in.

What is "unwind compatibility"?

The clang and gcc unwind libraries have slightly different interfaces.

thanks

It is quite unlikely that generic Linux distributions will switch to musl as it lacks support of locales and NSS.

Right, that's why I wrote "_a_ linux distro", not "some linux distros". I'm sorry for not making that clearer.

Can Clang/LLVM compile Linux itself?

A not-yet-fully-upstreamed branch maintained by the linux foundation can, yes. But just like FreeBSD has to make an exception to build certain packages with gcc, the kernel can be exclusively built with gcc for the time being. If you're not using musl libc, I guess glibc might also require gcc but that's an unsurprising coupling, likely due to gcc C extensions in use.

The important points are that such a distro will quickly improve the situation of clang and libc++ compatibility across the board and exercise the alternative toolchain a lot more. In fact, there isn't much incompatible code out there, and it's been fixed mostly due to efforts of Debian, FreeBSD and of course Apple and Bitrig and Gentoo. FreeBSD is the leading force behind making lld a viable alternative to binutils ld and so far ThinLTO (which works with binutils, to be clear) is exclusive to llvm, so there's that.

https://aur.archlinux.org/packages/llvmlinux-git/

http://llvm.linuxfoundation.org/index.php/Main_Page

Can you remind me why LLVM/CLANG can't compile the linux kernel? Is it dependance on GCC extensions?

TL;DR Yeah GCC specific compiler compiler extensions.

GCC has some platform specific symbols that are really just functions wrapping assembly. Most of this is related to crypto and AESNI (built in x86 AES operations). This breaks some crypto, which breaks some wifi/file system stuff.

XEN driver uses a GCC specific ASM macro for counting NUMA Nodes and CPU cores.

Dynamic compiling within the kernel for say BSD Packet Filtering JIT requires LLVM Compiler-RT have a custom wrapper. Also some libgcc specific header information.

I think those are mostly fixed for C code, but assembly still has issues. Otherwise dependence on exact gcc behaviour is an issue.

thanks

No.

https://llvm.org/bugs/show_bug.cgi?id=4068

https://www.phoronix.com/scan.php?page=news_item&px=Clang-Th...

It's not anytime soon that musl will replace libc.