fixing MinGW compilation

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

fixing MinGW compilation

Post by drfrag »

I got the MinGW build up and running, it took a few hours making it to compile and link. (I.R developer, I.R. smart. :) )
First i tried the mingw-w64 package i686-6.4.0-release-win32-sjlj-rt_v5-rev0.7z but failed misarably building the gdtoa target. So i've used the tdm-gcc 5.1 included with CodeBlocks. This is a mingw32 Debug build, there's a 64 bit version of tdm-gcc but no idea about that.
My changes for review are @ the g3.3mgw branch, someone could cherry-pick from there or i could do a PR. This is not the latest master but 3.3.2, i couldn't resist.
https://github.com/drfrag666/gzdoom/commits/g3.3mgw

There are a few problems: the truecolor software renderer crashes inmediately when r_multithreaded is set to true as soon as you start a new game. This is for the SSE2 version, the non SSE2 version works.
@dpJudas: is this to be expected? I mean, does this happen on any other platform? AFAIK this is a win32 native build not one running on a POSIX emulation layer (there's another mingw version for that). I've attached debugging info below.

Then the crash on exit in vmframe.cpp is still there, i'll update that thread now. That was a nasty crash and killed DirectX on win98, i don't think this version will work there. The non SSE2 version would crash now on old CPUs due to some later changes.

To set up the environment download CodeBlocks 17 from: http://sourceforge.net/projects/codeblo ... -setup.exe
Run the installer as an administrator just in case or the program dir won't be added to the path, i don't even know if this is really needed. Else you might need to add it manually to the system environment vars.
(batch file example: 'set PATH=C:\Program Files\CodeBlocks\MinGW\bin;C:\DEV\nasm-2.10.09;%PATH%')
(Add 'C:\Program Files\CodeBlocks\MinGW\bin;' to the Path variable)
Edit: it's needed or CMake would fail. Control panel->system->advanced system settings->environment vars.
For MinGW_w64 download i686-7.3.0-release-posix-sjlj-rt_v5-rev0.7z.

Add me as remote: https://github.com/drfrag666 and fetch from g3.3mgw
Then extract the code to a new folder or just clone the entire repo with copy-pasta to avoid screwing you VS cache.
Copy-pasta the following in CMake GUI (i use 3.9.6).
C:/Program Files/CodeBlocks/MinGW/bin/
C:/Program Files/CodeBlocks/MinGW/include/
C:/Program Files/CodeBlocks/MinGW/lib/
C:/Program Files/Microsoft DirectX SDK (November 2008)/Include (optional for XInput)
Edit: for MinGW-w64 change the paths to (for instance):
C:/DEV/mingw32/bin/
C:/DEV/mingw32/i686-w64-mingw32/include/
C:/DEV/mingw32/i686-w64-mingw32/lib/

Select CodeBlocks MinGW generator. Run the project and in project->build options modify zdoom's make commands (build project and compile single file adding -j2 before the -f).
Then project->properties, in build targets all select GUI application and type gzdoom.exe.
Settings->debugger GDB C:\Program Files\CodeBlocks\MinGW\bin\gdb32.exe
Edit: for MinGW-w64 C:/DEV/mingw32/bin/gdb.exe
Save the project.
For debugging open debugging windows (should just open automatically).
When debugging as soon as you can type set logging on debug.log for instance to log to a file.

You'll see the toolchain it's not bad at all, the weakest link is the debugger but it's okay for basic debugging i guess. If you need help let me know.

Debugging info for the multithreaded truecolor crash:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
Loop<swrenderer::DrawWall32TModes::SimpleShade, swrenderer::DrawWall32TModes::NearestFilter> (shade_constants=..., thread=0xaeb4818, this=0x11747390) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_draw_wall32_sse2.h:92
C:\DEV\vsqzdoom\src\swrenderer\drawers\r_draw_wall32_sse2.h:92:3471:beg:0xb86591
>>>>>>cb_gdb:inv_desaturate = {4294968400, 570277803283447808}
fracstep = 118238304
frac = 11218458
ssecount = 118238304
textureheight = 128
inv_light = {1271420150815718884, 19791020617432580}
vpz = 1.054547e-034
stepvpz = 1.84971397e-042
viewpos_z = {1.054547e-034, 9.70126072e+033, 9.4968106e-034, 3.13847248e-038}
dest = 0x70c2c60
dest_y = 1320
srcalpha = 11218458
source = 0xbbeab48
shade_light = {863989571435375608, 48142949845827584}
destalpha = 1104
source2 = 0x0
shade_fade = {118238200, 48145892194450668}
desaturate = 11208642
count = 201163248
num_lights = 296025324
one = 33554433
light = 51
mlight = {0, 72262240935673116}
pitch = 0
texturefracx = 296025324
lights = 0x12adfe0 <DrawerThreads::Instance()::threads>
step_viewpos_z = {1.054547e-034, -nan(0x7fffff), 0, 6.92150845e+032}
>>>>>>cb_gdb:shade_constants = {light_alpha = 0, light_red = 256, light_green = 256, light_blue = 256, fade_alpha = 0, fade_red = 0, fade_green = 0, fade_blue = 0, desaturate = 0, simple_shade = true}
thread = 0xaeb4818
this = 0x11747390
>>>>>>cb_gdb:#0  Loop<swrenderer::DrawWall32TModes::SimpleShade, swrenderer::DrawWall32TModes::NearestFilter> (shade_constants=..., thread=0xaeb4818, this=0x11747390) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_draw_wall32_sse2.h:92
#1  swrenderer::DrawWall32T<swrenderer::DrawWall32TModes::OpaqueWall>::Execute (this=0x11747390, thread=0xaeb4818) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_draw_wall32_sse2.h:67
#2  0x00479806 in DrawerThreads::WorkerMain (this=0x12adfe0 <DrawerThreads::Instance()::threads>, thread=0xaeb4818) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_thread.cpp:129
#3  0x00479964 in DrawerThreads::<lambda()>::operator()(void) const (__closure=0xbf10e38) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_thread.cpp:159
#4  0x004ab427 in std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()>::_M_invoke<>(std::_Index_tuple<>) (this=0xbf10e38) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/functional:1531
#5  0x004ab346 in std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()>::operator()(void) (this=0xbf10e38) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/functional:1520
#6  0x004ab2ac in std::thread::_Impl<std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()> >::_M_run(void) (this=0xbf10e2c) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/thread:115
#7  0x00a7f700 in execute_native_thread_routine ()
#8  0x070c2c60 in ?? ()
#9  0x00000001 in ?? ()
>>>>>>cb_gdb:#2  0x00479806 in DrawerThreads::WorkerMain (this=0x12adfe0 <DrawerThreads::Instance()::threads>, thread=0xaeb4818) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_thread.cpp:129
C:\DEV\vsqzdoom\src\swrenderer\drawers\r_thread.cpp:129:3683:beg:0x479806
>>>>>>cb_gdb:command = @0xb38bc60: 0x11747390
__for_range = @0x7ea0874: {<std::_Vector_base<DrawerCommand*, std::allocator<DrawerCommand*> >> = {_M_impl = {<std::allocator<DrawerCommand*>> = {<__gnu_cxx::new_allocator<DrawerCommand*>> = {<No data fields>}, <No data fields>}, _M_start = 0xb38bc60, _M_finish = 0xb38eeb4, _M_end_of_storage = 0xb38fc60}}, <No data fields>}
__for_begin = {_M_current = 0xb38bc60}
__for_end = {_M_current = 0xb38eeb4}
start_lock = {_M_device = 0x12adfec <DrawerThreads::Instance()::threads+12>, _M_owns = false}
list = {<std::__shared_ptr<DrawerCommandQueue, (__gnu_cxx::_Lock_policy)2>> = {_M_ptr = 0x7ea0870, _M_refcount = {_M_pi = 0x7ea08a0}}, <No data fields>}
end_lock = {_M_device = 0x6f250c10, _M_owns = 12}
finishedTasks = 17
>>>>>>cb_gdb:this = 0x12adfe0 <DrawerThreads::Instance()::threads>
thread = 0xaeb4818
>>>>>>cb_gdb:#0  Loop<swrenderer::DrawWall32TModes::SimpleShade, swrenderer::DrawWall32TModes::NearestFilter> (shade_constants=..., thread=0xaeb4818, this=0x11747390) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_draw_wall32_sse2.h:92
#1  swrenderer::DrawWall32T<swrenderer::DrawWall32TModes::OpaqueWall>::Execute (this=0x11747390, thread=0xaeb4818) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_draw_wall32_sse2.h:67
#2  0x00479806 in DrawerThreads::WorkerMain (this=0x12adfe0 <DrawerThreads::Instance()::threads>, thread=0xaeb4818) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_thread.cpp:129
#3  0x00479964 in DrawerThreads::<lambda()>::operator()(void) const (__closure=0xbf10e38) at C:/DEV/vsqzdoom/src/swrenderer/drawers/r_thread.cpp:159
#4  0x004ab427 in std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()>::_M_invoke<>(std::_Index_tuple<>) (this=0xbf10e38) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/functional:1531
#5  0x004ab346 in std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()>::operator()(void) (this=0xbf10e38) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/functional:1520
#6  0x004ab2ac in std::thread::_Impl<std::_Bind_simple<DrawerThreads::StartThreads()::<lambda()>()> >::_M_run(void) (this=0xbf10e2c) at C:/PROGRA~1/CODEBL~1/MinGW/lib/gcc/mingw32/5.1.0/include/c++/thread:115
#7  0x00a7f700 in execute_native_thread_routine ()
#8  0x070c2c60 in ?? ()
#9  0x00000001 in ?? ()
Last edited by drfrag on Fri Apr 27, 2018 1:37 am, edited 5 times in total.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

I'm getting warnings in i_crash.cpp in the __declspec(thread) lines: warning: 'thread' attribute directive ignored. This could be related to the crash but no crash with the no SSE version.
Also i'm not sure about this one:
https://github.com/drfrag666/gzdoom/com ... 5a451a4f71

From the gcc docs:

Code: Select all

-mthreads
    Support thread-safe exception handling on Mingw32. Code that relies on thread-safe exception handling must compile and link all code with the -mthreads option. When compiling, -mthreads defines -D_MT; when linking, it links in a special thread helper library -lmingwthrd which cleans up per thread exception handling data. 
What could i do? :3:
Graf Zahl wrote: a Windows compiler that isn't fully compatible with Windows code is not going to fly.
Do you mean the manifest? I got and error in the CONTROL 101 line, the older versions didn't even compile it. Is it that important?

Edit: i've changed __declspec(thread) for __thread for MinGW. Now recompiling.
Edit2: nope, still crashes.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

@dpJudas:
I've noticed that the poly renderer also crashes (8 and 32 bit) with r_multithreading on. The carmack renderer only crashes in truecolor mode.
SSE2 multithreaded, that is.
So no idea of what's going on. Any help would be appreciated. Thanks. :wub:
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: fixing MinGW compilation

Post by Graf Zahl »

AFAIK __declspec(thread) is the non-standard predecessor of 'thread_local'. Obviously ignoring such a thing is a surefire way to cause problems.
Regarding the other problems you have, didn't I tell you about a "Windows compiler that isn't compatible with Windows?"
I'm not really surprised that it has problems with some advanced concepts
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: fixing MinGW compilation

Post by dpJudas »

I can only really echo here was Graf said. The multi-threaded software render code is working perfectly fine on three platforms with the platform compilers (msvc for Windows, gcc for Linux and clang for macOS). As a result, I can only conclude this is a mingw compatibility issue.

Of all the things I want to spend my leisure time on, debugging mingw-only issues is extremely far down my list. I'm sorry, but I am not willing to do this kind of work on a volunteer basis.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

dpJudas wrote:I can only conclude this is a mingw compatibility issue.
Thanks, that's all i needed to know. I was not sure i hadn't messed up anything, specially that "Fixed improved crash handling in drawers not compiling with mingw32" commit. You mentioned in the past that r_multithreaded was not thread safe but it has to be now.
I posted that trace just in case someone saw something strange. Also r_multithreaded wouldn't be important in a Legacy build.
Graf Zahl wrote:AFAIK __declspec(thread) is the non-standard predecessor of 'thread_local'. Obviously ignoring such a thing is a surefire way to cause problems.
I already changed it for __thread.
On the crash on exit if you're completely sure that's a MinGW thing and not some issue in the VM waiting to strike hard later then it's not worth fixing it. I always could add a hack (the exiting global variable again). :) But i've sucessfuly debugged some stuff with this environment and then the fixes were portable.

But all in all this is not my stuff, this is for GZDoom. According to what Rachael said GZDoom should compile with MinGW and my help to fix up the code to compile with MinGW was welcome. Of course the solution could be anhanced and simplified. It's better than leaving it in its current broken state.
Another possibility would be to remove completely MinGW support but that would be far more work than adding a few patches and i don't think that would be a good idea. It's up to you to decide of course. Also i could try with the MinGW-w64 7.3 package.
Blzut3 was the MinGW guy but seems he only visits the forum on rare ocassions.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: fixing MinGW compilation

Post by Graf Zahl »

The main issue with MinGW is not to fix it but to ensure its continued functionality.

I do not use this compiler, and AFAIK neither do any of the other developers, so whatever happens now, it is likely that stuff will break again, especially if you have to #ifdef larger sections of code to make it work to begin with.
Every single MinGW #ifdef is a future cause of errors.
I already changed it for __thread.
Why not thread_local?
Using __declspec(thread) wasn't a good idea, replacing it with another compiler specific keyword is even less, especially when something official exists.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: fixing MinGW compilation

Post by _mental_ »

MinGW can be added to Appveyor config. The problem is it builds target one by one, not simultaneously like Travis.
So, every new target will prolong verification of a commit. The main issue however is still no interest in using MinGW locally.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: fixing MinGW compilation

Post by Rachael »

Graf Zahl wrote:I do not use this compiler, and AFAIK neither do any of the other developers
I believe you are correct, here. I can at the very least assert that it's true for me.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

Some ifdefs could be removed, they are there to preserve the original code. I don't see why MinGW ifdefs are a future cause of errors.
Graf Zahl wrote:Why not thread_local?
Using __declspec(thread) wasn't a good idea, replacing it with another compiler specific keyword is even less, especially when something official exists.
Becouse the original version used __declspec(thread) and i read in CMake that thread_local was optional for now.

I've tried i686-7.3.0-release-win32-sjlj-rt_v5-rev0.7z and it's the same as 6.4. This time from the command line. The makefile fails generating arith.h (gtoa target), giving a crazy error number. The output of arithchk.exe is empty and copying the right arith.h won't help since the makefile deletes it unconditionally.

Edit: now i know that happens. The arithchk.c file includes <stdio.h> and not <windows.h> and only gives output when run inside MSYS2 but not from the command prompt. It's crazy i know, i'll try to find a workaround.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: fixing MinGW compilation

Post by Graf Zahl »

I hope you now start to understand why nobody here wants to bother with this strange piece of software.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

Actually that was what people commented in forums but apparently is a lie. I've installed MSYS2 and it's the same. Seems like command line executables generated with MinGW-w64 are broken/non functional. The updaterevision.exe also failed and then i gave up. It's crazy they claim DX11 support. Yes, MinGW-w64 is a pile of shit. It's made by a different developer team, original MinGW and TDM-GCC worked well tough.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: fixing MinGW compilation

Post by Rachael »

I wouldn't be so quick to condemn an entire compiler suite as being a piece of shit over a few simple bugs. :P

The fact that so few people use it add to its issues, though - they cannot account for every edge case because there's simply not enough real world scenarios going through the test phases. If you want to improve that - that information you've gotten from attempting to do this is very valuable to them, and likely will improve the compiler in the future.

If you want to continue using MinGW for GZDoom - either 32 or 64 - you can go and report these issues to them. Compiler diversity is never a bad thing - it's when there are issues with the compiler, itself, that it becomes a problem.
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: fixing MinGW compilation

Post by Chris »

MinGW-w64 is a pretty good compiler. It's certainly not perfect, but it's suitable for most things that don't assume MSVC on Windows (especially compared to Cygwin, which is just.. ugh..). It's also the only real choice for cross-compiling, to generate Windows executables if you're on Linux. I don't know the status of MinGW32 these days, but I know before it went years without updating its headers (it didn't even properly support DirectX 8 or 9, IIRC; you needed to grab headers and libs from third-party sources), dragged their feet on 64-bit support, and they were very slow to respond to a severe bug that was exposed with Windows Vista, which caused many MinGW32-built apps to fail to load. That eventually caused people to fork it and create the MinGW-w64 project with more responsive updates, support for 64-bit targets, and better support for modern Windows APIs.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: fixing MinGW compilation

Post by drfrag »

Rachael wrote:I wouldn't be so quick to condemn an entire compiler suite as being a piece of shit over a few simple bugs.
I never said it was a piece, i said pile :mrgreen: . The console executables just exit cleanly without any output, they can't create files either. Tomorrow i'll test a simple hello world c program and we'll see. I'm on win 8.1 BTW.
Chris wrote:MinGW-w64 is a pretty good compiler.
I've used MinGW and DJGPP before that and they worked fine then. Also ZDoom LE is built with tdm-gcc and works 100%. Have you ever tried to build ZDoom with MinGW-w64? I know Chocolate Doom builds with it.
Post Reply

Return to “General”