MSYS2-packages VS mingw-w64

Google says (1, 2, 3) that this issue is caused by Avast/AVG antivirus moving some executable files (bash.exe in your case, seemingly) into its quarantine folder.

It's a known issue: https://github.com/msys2/MSYS2-packages/issues/3150

Could you let me know of this is perhaps relevant to you? I will investigate sometime this week! Thanks for bringing this to my attention.

I am still on WSL1 due to the filesystem performance with WSL2. I recently tried to move more of my workflow towards MSYS2 but various things keep breaking for me without obvious reasons.

Latest issue I encountered was that GNU parallel simple does not work. [1]

[1]: https://github.com/msys2/MSYS2-packages/issues/3289

I've already tested the rest of the tools needed for the build process (just Python 3.10 and PyInstaller) and they seem to work fine. My issue is that both MSYS2 and Cygwin do not work in WINE (this is pretty well documented: MSYS2, Cygwin), so I don't know of any other means of getting the Windows versions of GTK3 libraries in my WINE prefix so that PyInstaller can pack it all up for me.

It's old bug with gcc standard library implementation which has not been fixed, I guess most likely nobody made a bug report. I tested it myself and indeed it doesn't work properly and we are not alone: https://github.com/msys2/MSYS2-packages/issues/1937.

My last experience with MinGW-w64 was when I was trying to compile my C++ simulation code in Windows and finding out that AVX instructions were not working because the compiler had misalignment-related bugs. (The issue is still open in https://github.com/msys2/MSYS2-packages/issues/1209)

MinGW/MSYS certainly had appeal to former Linux devs who didn't want to touch the horrors of MSVC, but Zig (with its included Clang compiler/runtime) might end up being a better solution for people trying to compile C/C++ code on Windows in a stable manner.

> I actually did this, to make it error out cleanly instead of having to debug this very non-obvious issue, quite recently: https://github.com/mingw-w64/mingw-w64/commit/ca35236d9799af...

Thanks! I believe this will save many people a lot of time in their debugger.

> The runtime pseudo relocation fixing code ends up linked into your executables even if the executable doesn't use any runtime pseudo relocations - so essentially all MinGW programs will end up importing this function. That doesn't mean it does get called though.

Oops. Not a big deal, though; I assume it won't get called if the table is empty.