3 ms·

I used to use mingw to cross-build a project. At one point, after updating the toolchain from gcc 4.x to 7.x and from mingw32 to mingw-w64, it started to produ

I used to use mingw to cross-build a project. At one point, after updating the toolchain from gcc 4.x to 7.x and from mingw32 to mingw-w64, it started to produce broken binaries. The manifestation of that brokenness was that binaries refused to start properly on systems where the toolchain was not installed. It just silently exited during startup - no crash, or error message, or anything. This applied both to binaries that were cross-built on linux, and binaries built using MSYS2 on Windows. I decided to just switch to clang-cl + MSVC headers instead, which worked properly. The only gotcha there was the need to store the headers on a case insensitive file system (I chose vfat) when compiling on linux, because the case of the includes aren't consistent (e.g. Windows.h vs. windows.h), even in the MSVC headers themselves.

tavert 9y ago
were you missing compiler runtime libraries? like any code compiled with gcc anywhere that links the runtimes as shared libraries, they'll need to be present for executables to run. depending which variant of mingw-w64 you used, there are more runtime library dependencies than there used to be, like winpthreads for c++11 thread support.
- aepiepaey 9y ago
  Fairly certain that wasn't the case. As far as I could tell, the only DLLs the binaries referenced were msvcrt.dll and standard windows DLLs (KERNEL32, USER32, etc). The application was also plain C. Even if missing compiler runtime libraries were the issue, I would have expected the program crash or fail with an error message.