[Dwedit]

MSYS2 is very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building.

It doesn't help that the package simply named "gcc" is for the MSYS2 target.

[jasomill]

And just to add insult to injury, you probably don't want MINGW64 either, as it relies on the ancient MSVCRT.DLL C runtime library that lacks support for "new" features like C99 compatibility and the UTF-8 locale, and that Microsoft never supported for use by third-party applications in the first place.

Instead, you either want UCRT64 or CLANG64, depending on whether you want to build with the GNU or LLVM toolchains, as it uses the newer, fully-supported Universal C Runtime instead.

[Dwedit]

It's still useful to use MSVCRT in certain circumstances, such as targeting the earliest 64-bit versions of Windows.

As for UTF-8 support, it's the manifest file that determines whether Windows sets the ANSI code page to UTF-8. (There's also an undocumented API function that resets the code page for GetACP and the Rtl functions that convert ANSI into Unicode. But this would run after all the other DLLs have finished loading.) Having the code page correct is enough to support Unicode filenames and Unicode text in the GUI.

It just won't provide UTF-8 locale support for the standard C library.

[jasomill]

Sure, or older 32-bit versions of Windows for that matter, or for building software that hasn't been ported to UCRT.

I can certainly relate to this: I'm currently sitting on a request for an enhancement to a product (currently running on a 32-bit Windows 10 VM) with a build system that has never been updated to support any Microsoft platform other than MS-DOS, or toolchain newer than Microsoft C 5.1.

[mynameajeff]

> lacks support for "new" features like C99 compatibility

This made me laugh. It reminded me of course work I did in university that was clearly written many years before I took the course as it recommended we manually enable the "new" c99 standard in our compiler, which I guess survived in the documentation up through when I took the course, at which point it was still relevant since GCC was otherwise defaulting to C11 by the time I was using it.