[Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Thiago Macieira wrote:

> On Wednesday, 19 July 2023 23:48:43 PDT Martin Storsjö wrote:
>> Switching with those flags works, as long as you're building a C-only
>> executable and linking libgcc statically (and not linking in any static
>> libraries that were built for another CRT). I'm pretty sure that libstdc++
>> touches lots of the things that have a differing ABI. A shared linked
>> libgcc will use the CRT that the toolchain was built with - although I'm
>> not sure if libgcc shares any CRT objects across the DLL boundary (whether
>> it is a real issue or just messy).
>
> Thanks, Martin.
>
> I was aware of this, but thanks for expanding on who it's really a binary-
> incompatible choice.
>
> For $DAYJOB project[1], we build the compiler itself and the libraries we
> need, linking statically to all of them.... except libmingw & libwinpthread. I
> need to check what those import and if they are binary-compatible.

Yeah, as there's so many different ABI affecting choices especially around 
here, building all the libraries yourself is definitely the recommended 
way to go IMO as well.

So are you saying that you're building your app with a non-default CRT 
selected with the -mcrtdll option?

If you use the GCC -mcrtdll option for picking a non-default CRT, it would 
work unless you're also linking, even statically, a toolchain-provided 
libstdc++ though. I'm pretty sure that at least some parts of libstdc++ 
touch things that have a differing ABI, even if most things might seem to 
work.

The msys2-carried old patch only switches what library to link against, 
but a recently upstreamed one, 
https://github.com/gcc-mirror/gcc/commit/453cb585f0f8673a5d69d1b420ffd4b3f53aca00, 
also sets matching flags for at least picking the right definitions from 
headers as well. The CRT switching flag from that commit, plus recompiling 
everything (and staying away from libstdc++) should generally achieve the 
same as using a purpose-configured toolchain.

The libmingw* parts (libmingw32.a and libmingwex.a) are intended to be 
CRT-agnostic - I'm not aware of any parts in them relying on things with a 
differing ABI or interface. A statically linked libgcc also probably is 
fine. For libwinpthread, I'm not sure though.

// Martin