Problems shipping binaries with MSYS2/MINGW64

SDL Development
1

Does anyone here use MSYS2 and any of it’s toolchain environments to ship windows builds of SDL2 applications?

I’ve got an SDL2/GLES3 + SDL2_mixer game which runs fine when compiled and launched from the MSYS2 env itself. But when trying to prep a distribution, I’m running into issues.

I’ve checked the output of ldd, and copied every DLL which isn’t provided by Windows in System32.

When just double-clicking on the binary outside of the MSYS2 env, the process starts (so I’ve got all the DLLs in place), but no window comes up.

I’ve navigated to where I’ve stored the binary outside of the MSYS2 path, and checked the linker output, all the dependencies are filled either by System32 DLLs, or by the DLLs in the same directory. I’ve also tried whitelisting the folders in Windows Defender, in case it was getting flagged, but no change.

Any suggestions? How do folks ship for Windows? I was hoping to avoid committing the entirety of SDL, or learning vkcpkg/conan/etc.

2

In general, you should never modify system32 content by-hand. Instead, always copy additional DLLs in the same directory of your .exe

SDL will try to detect video/audio/etc backend dynamically; unloadable backend will be silently skipped. Thus, ldd might not provide complete dependency since ldd will only show DLLs which are absolutely required to start the process.

Tools like Process Explorer - Sysinternals | Microsoft Learn will provide DLL list(View → Lower pane view → DLLs) which is actually loaded in running process so it might be worth to try.

3

Yesssss, I was missing one DLL that must be loaded dynamically! Thank you so much <3

4

Which one?

With MINGW builds it’s often libgcc_*.dll (unless you use -static-gcc) and/or libwinpthread-1.dll (esp. when building C++ code, because the windows/mingw port of libstdc++ uses pthreads for windows)

5

it was EGL actually, the three you mentioned are actually in the ldd output