use VC and not mingw.

Can't really help except to say that if you have identified issues with msys2/mingw64/gcc then it's best to report them to the respective team.

Had an issue a couple of months ago that took me and gandhig forever to figure out with MINGW where compiled executables were not working on 3.51,95 and 98. (nothing to do with the issue in the linked thread)

Eventually tracked it down to a bug with newer versions of the mingwrt package that assumes SSE support on Operating Systems that don't support it but the CPU does.
https://sourceforge.net/p/mingw/bugs/2357/

Reason issues like this crop up is because most lazy people use mingw packages already provided with whatever IDE they use or give up and just use older versions without tracking down the issue and reporting it.

So if you find an issue with msys2/mingw64/gcc please report it!

Contratry to the posts in that forum I have no complaints with mingw64 but I've only really used it mainly for compiling DOSBox which was much easier to put together a working environment than with mingw. Without looking at the code it's hard to say if it's an issue with the gzdoom code, mingw64 package or gcc issue. If the exe compiled but cannot run I'm leaning towars a mingw64 package.

Is there a list of advantages of using ming-w64 over ming-w32?

Thanks, i thought MinGW was dead. Yes, this is a very different problem.

Some news:
I've compiled a hello world style simple program and surprisingly it works. :?
I've rebuilt targets in the other folder using tdm-gcc and then i've copied the exes and .h. I've managed to compile the source but i got the wrong package, i needed i686-7.3.0-release-posix-sjlj-rt_v5-rev0 for the pthreads stuff (tdm-gcc already had some stuff from mingw-w64). Of course exes are still non functional.
I've fixed an usage of the old Monkeysoft _declspec and now compiles but after copying a lot of dlls the exe just exits cleanly like the other ones. With gdb i get the message inferior 1 exited with code 0375 (more numbers follow). No idea of what's going on.

MinGW-w64 requires win xp but is supposed to have better multithreading support. With tdm-gcc i get a crash in the software renderer using r_multithreaded. Also there's a crash on exit in the VM. It's a more recent version of gcc and it's supposed to have even DX11 support. Also you can build 64 bit executables.

Edit: just created a ticket @ sourceforge.
https://sourceforge.net/p/mingw-w64/bugs/726/

It doesn't seem possible that arithchk.c will not build correctly with any ming-w64 package. The source file is dependent on just stdio.h, so it is one step more complex than "hello world". Is it possible to build arithchk outside gzdoom and test, like done for hello world? At least one of the ming-w64 package versions must be able to build it correctly. I would also test on another machine, if not.

Good idea. The arithchk executable is working when compiled separately without any flags. So some flag is screwing the executables.

1Building C object gdtoa/CMakeFiles/arithchk.dir/arithchk.c.obj
2cd /d C:\DEV\msys32\g33mgw\release\gdtoa && C:\DEV\msys32\mingw32\bin\gcc.exe -DINFNAN_CHECK -DMULTIPLE_THREADS @CMakeFiles/arithchk.dir/includes_C.rsp -ffp-contract=off -fPIE -Wall -Wextra -g  -D_DEBUG -D_DEBUG   -o CMakeFiles\arithchk.dir\arithchk.c.obj   -c C:\DEV\msys32\g33mgw\gdtoa\arithchk.c
3Linking C executable arithchk.exe
4cd /d C:\DEV\msys32\g33mgw\release\gdtoa && C:\DEV\cmake-3.9.6-win32-x86\bin\cmake.exe -E cmake_link_script CMakeFiles\arithchk.dir\link.txt --verbose=1
5C:\DEV\cmake-3.9.6-win32-x86\bin\cmake.exe -E remove -f CMakeFiles\arithchk.dir/objects.a
6C:\DEV\msys32\mingw32\bin\ar.exe cr CMakeFiles\arithchk.dir/objects.a @CMakeFiles\arithchk.dir\objects1.rsp
7C:\DEV\msys32\mingw32\bin\gcc.exe  -ffp-contract=off -fPIE -Wall -Wextra -g  -D_DEBUG -D_DEBUG   -pie -Wl,--whole-archive CMakeFiles\arithchk.dir/objects.a -Wl,--no-whole-archive  -o arithchk.exe -Wl,--out-implib,libarithchk.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\arithchk.dir\linklibs.rsp
8mingw32-make[2]: Leaving directory 'C:/DEV/msys32/g33mgw/release'
9Built target arithchk
10C:/DEV/msys32/mingw32/bin/mingw32-make -f gdtoa\CMakeFiles\qnan.dir\build.make gdtoa/CMakeFiles/qnan.dir/depend
11mingw32-make[2]: Entering directory 'C:/DEV/msys32/g33mgw/release'
12Generating arith.h
13cd /d C:\DEV\msys32\g33mgw\release\gdtoa && .\arithchk.exe >C:/DEV/msys32/g33mgw/release/gdtoa/arith.h
14mingw32-make[2]: Leaving directory 'C:/DEV/msys32/g33mgw/release'
15mingw32-make[1]: Leaving directory 'C:/DEV/msys32/g33mgw/release'
16
17mingw32-make[2]: *** [gdtoa\CMakeFiles\qnan.dir\build.make:61: gdtoa/arith.h] Error 295720572
18mingw32-make[2]: *** Deleting file 'gdtoa/arith.h'
19mingw32-make[1]: *** [CMakeFiles\Makefile2:780: gdtoa/CMakeFiles/qnan.dir/all] Error 2
20mingw32-make: *** [Makefile:129: all] Error 2

Is it possible to build a standalone working arithchk with those flags and with some subset of the flags? Does it work with and without the PIE/pie option?

Thanks, it was the fPIE option.

It's fixed, the fPIE flag added recently for linux broke the MinGW-w64 executables, it was ignored with tdm-gcc.
It was this commit:
https://github.com/coelckers/gzdoom/commit/25 … 4020c5bc0481225
Fix here:
https://github.com/drfrag666/gzdoom/commit/1a … 61ee62bb3cd62fe

So now it works and no longer crashes with r_multithreaded on, this compiler has better multithreading support. But still crashes in the VM on exit, i doubt it's a problem with MinGW. Now i'd need to do some cleanup.

The crash on exit, was that tested with a fully debug build? And verified dependency on the mingw-w64 debug libraries? Does the mingw-w64 system support fsanitize=thread and fsanitize=undefined for testing?

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.

Addressing the fluidsynth issue first, if that's ok, there is alternate win32 no-glib source code that may help:
Fluidsynth soundfont patch

I've tried your fluidsynth dll and apparently runs fine (tested on win 8.1 for now). Sounds the same to me as the later version and it seems to be using gzdoom.sf2.

Now, should we target win98? The best thing would be to build a MinGW-w64 cross compiler to target win98 but i don't know how. Or just using tdm-gcc disabling multithreading. Another problem would be finding an older OpenAL still working there and with GZDoom.
There's a problem with framerate on my 1 GHz P3 on win 98, with cl_capfps i get half the framerate and the game is choppy even @320 with 150 fps. Then someone should test on XP with a P3 or with an Athlon XP on 98.

On the crash on exit i think it could be a bug in MinGW-w64-crt and MinGW-crt, if so we only could add a workaround and report the bug. It doesn't crash on linux nor with VS. I can't think of a better solution that the exiting global variable to kick it out of there and return NULL (leaking memory on exit it's not important). I already did a similar thing for the crash in gl_material.cpp in my legacy ports.

Did a fully debug version show any difference in the framerate and exit issues? Also, is it possible to test with the win32 multithreading version of mingw-w64, or is the win32 zdoom32 code dependent on the posix threads?

It seems that the main gzdoom builds already coincide with the STEAM api requirements, including the language requirement. If that is true, it would make it simple to commercialize their open source port.

I tried only a Release (O3) build, a Debug build would be too slow i think. I don't know if choppiness is a win98 or p3 problem.
The crash on exit happens with all builds. It was there already in GZDoom 2.4 (rzdoom branch) and i think since the zscript merge. ZDoom32 had the old C++ drawers and multithreading was then still experimental but somewhat worked. It compiled with tdm-gcc which included (somewhat poor) pthreads support from MinGW-w64.

GZDoom now uses the GPL v3 and i know there are some indie games being developed based on it.

The debug build may help test the crash on exit issue, at least it would just require a recompile as opposed to the usual debugging procedures. Is it possible to verify older built versions for the crash on exit issue, too? Also, if I read a previous post correctly, is there an obvious reason why the exit via console doesn't crash whereas the other exit functions do?

For the threading issue, I assume that the Visual Studio builds rely on win32 multithreading. Given that is true, is it possible to use those routines with mingw-w64 instead of the posix multithreading functions?

I don't know what you mean, i obtained the stack trace using a debug build and Code::Blocks. I posted the traces at that ZDoom thread.I cannot post a debug build since it weights more than 50 MB. But there are instructions to quickly setup the environment at the MinGW thread here: https://forum.zdoom.org/viewtopic.php?f=4&t=60338
It's the same crash in all versions even with an old Blzut3 build. That build is here and is a Debug build: http://maniacsvault.net/loosefiles/gzdoom-mingw-20170122.7z
No idea sorry.
The VS build uses the same code, C++11 threads. Multithreaded doesn't crash with MinGW-w64, only with tdm-gcc. MinGW-w64 targets win xp.

Attached test release tdm-gcc 5.1 build, sound is not working on 98 and r_multithreaded crashes (of course this is a software renderer thing) with swtruecolor on. 8 bit rendering is slower with tdm-gcc. I'd appreciate someone could test this on win 98 K7 and win xp P3 machines. The file will be available for a few days.
http://www.fileconvoy.com/dfl.php?id=gb26d378 … 7768bf745dad33b
Edit: updated link with hail_to_the_rayzen's fluidsynth version, the other one gave a runtime error. But this version won't work either on 98.

Thank you for the information. I must have mistakenly read your post as release with debug info.

I've just edited previous post, MinGW-w64 cannot target win 98.

Not sure what you mean by that I can compile a program and then execute it on NT 3.51+ using mingw-w64 x32 as long as the OS is run on an i686 and you use the msvcrt from Q932590.zip

Last tested with mingw-w64 7.1.0 dwarf 32

Post 669269