On Mon Jan 27 12:18:01 2025 +0000, Martin Storsjö wrote:
So is there no way to compile C++ stuff with Clang MSVC without using
Microsoft's proprietary C++ runtime? Not that I'm aware of, no. Feel free to work on reimplementing what's missing though :-) Microsoft did offer some parts of what libc++ needs under a suitable license, so that libc++ could reduce its reliance on MS STL (parts about the exception classes, IIRC), but that bit hasn't been integrated yet, and I would think that more parts are required to make it entirely standalone.
Admittedly my terminology was befuddled, but I believe I wasn't intentionally "mixing things up."
MinGW(-w64) demands constructs like `__MINGW32__`, `__attribute__((ms_struct))`, and the Itanium C++ ABI (for x86_64) from the compiler. Initially only GCC supported them, and then Clang had to follow suit by matching GCC's semantics. LLVM eventually had to gain two separate modes (MinGW and MSVC) just for Windows PE target because MinGW has its own set of "C(++) extensions" incompatible with MSVC (which defines `_MSC_VER` instead, has ms struct semantics by default, and has its own C++ ABI).
On ARM64, the role is reversed: LLVM got to decide first what the aforementioned MinGW constructs mean on Windows ARM. Now, if GCC is to ever support ARM64, it has to be compatible with whatever semantics Clang has already decided along while GCC's support was "lagging behind." IMO it doesn't make sense for MinGW to distinguish between "GCC MinGW mode" and "Clang MinGW mode." The former has to emulate the later.
In that sense, MinGW (while ostensibly being just "headers and libraries") actually introduces a lot of stuff into the toolchain landscape like the choice of C++ ABI (incompatible with MSVC) as well as its own set of macros and extensions. This is what I meant by "MinGW going its own way with Clang, without GCC counterpart."