The State of Toolchains in OpenBSD

&gt; The main reason has to be newer C and C++ standards support.<p>Ironically clang is now behind gcc and VC++ regarding newer ISO C++ support.<p><a href="https:&#x2F;&#x2F;en.cppreference.com&#x2F;w&#x2F;cpp&#x2F;compiler_support" rel="nofollow">https:&#x2F;&#x2F;en.cppreference.com&#x2F;w&#x2F;cpp&#x2F;compiler_support</a>

The licence mailthread in the LLVM list (pointed to in the article) is brutal.<p>Moving to a licence otherwise deprecated is a huge deal. For a &quot;no compromise&quot; community (OpenBSD), its huge++<p>But, the pragmatism appears useful: without this, modern hardware cannot be compiled to optimally. It was a least-worst choice decision.

Why was the compromise made for LLVM 10 with the Apache license and not for GCC with the v3 GPL license?

I&#x27;m curious whether it would be okay to optionally support other toolchains. For example, if openbsd works when built with GCC 4.x but also can build with GCC 10.x, it remains &quot;safe&quot; with the older GPLv2 GCC but a person wanting performance <i>could</i> opt to use the latest version. Or is that tempting a slippery slope?

I just reviewed 2 m68k patches to LLVM today; I expect we should be able to build the m68k port of the Linux kernel with LLVM soon.

I hope they will do the transition from CVS too.