Certainly your help on this would be very welcome, the crash is being discussed with stack trace here:
https://forum.zdoom.org/viewtopic.php?f=4&t=60217
With CMake there are options to enable the address and undefined behavior sanitizers but i haven't tried, this could be a gcc or MinGW bug or not. Edit: the sanitizers are not supported in MinGW.
Some news, GZDoom now runs on non SSE2 cpus again. The software drawers for the rasp pi work in x86 as well, on an athon xp the game runs fine but on a p3 it's a bit choppy i guess due to the new timing code. I also had to recompile OpenAL and fluidsynth, this last one depends on a lot of dlls and i've been suggested to 'build all FluidSynth dependencies as static libraries' but i don't know how (i'm using 1.1.10) For OpenAL i've tried 1.17.2.
https://github.com/FluidSynth/fluidsynth/wiki … ildingWithCMake
On windows 98 (tdm-gcc 5.1 build) i get no sound since OpenAL no longer works, i guess that's normal and i'd need to use an older version. Also r_multithreaded crashes, a minor problem for a legacy build. But is it worth to target win98 for such a modern version?
Now i think the problem with -fPIE is a MinGW-w64 bug and that flag should be ignored but the ticket was closed.
I've updated the instructions to instal MinGW-w64, you'd need the package i686-7.3.0-release-posix-sjlj-rt_v5-rev0.7z instead. Installing CodeBlocks is advisable for debugging since CMake can generate CodeBlocks style makefiles.
With your help we could do a legacy release, i could prevent the crash with a hack but i don't like the idea (the exiting global variable trick).
https://forum.zdoom.org/viewtopic.php?f=4&t=60338&start=60
One last thing, now they're doing a major refactoring and have removed d3d and ddraw. Also they are refactoring the GL renderer to allow for a future vulkan backend (everything runs thru GL 2 right now). Also i'd need to re-apply all the MinGW patches again after they're done with the refactoring and do a PR.