fixing MinGW compilation

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
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 »

drfrag wrote: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.
When MinGW came out, it was pretty good considering it was one of the few (if not the only) free Windows compiler available. It's just that over time it started to really lag behind with improvements and API updates.

I haven't tried to build ZDoom with MinGW-w64, no. That's mainly because I use Linux so I don't need to, but also cross-compiling ZDoom isn't that straight forward. Typically, cross-compiling with CMake means you specify a toolchain file that sets up the desired compiler tools and target environment, and the build script detects the target environment with the given host tools. However, ZDoom's build script expects to be able to generate and run executables as part of the build process, which it obviously can't do if the build target and host are different. The way ZDoom tries to work around this is requiring a host build first, then tell a cross-compile build to use the host build's executables, and I never really bothered to look too deep into trying that (FWIW, the way I handle a similar issue with OpenAL Soft is to make the build script launch a second cmake process without any custom toolchain to build a self-contained sub-project, generating any native executables that need to run on the host system; the main build can then run those native executables just fine).
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 »

Thanks, 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.

This one should be cherry-pickable (or just copy-pasta):
https://github.com/drfrag666/gzdoom/com ... c5144493a1

Edit: just created a ticket @ sourceforge.
https://sourceforge.net/p/mingw-w64/bugs/726/
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 progress:
The arithchk executable is working when compiled separately without any flags. So some flag is screwing the executables.

Code: Select all

Building C object gdtoa/CMakeFiles/arithchk.dir/arithchk.c.obj
cd /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
Linking C executable arithchk.exe
cd /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
C:\DEV\cmake-3.9.6-win32-x86\bin\cmake.exe -E remove -f CMakeFiles\arithchk.dir/objects.a
C:\DEV\msys32\mingw32\bin\ar.exe cr CMakeFiles\arithchk.dir/objects.a @CMakeFiles\arithchk.dir\objects1.rsp
C:\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
mingw32-make[2]: Leaving directory 'C:/DEV/msys32/g33mgw/release'
Built target arithchk
C:/DEV/msys32/mingw32/bin/mingw32-make -f gdtoa\CMakeFiles\qnan.dir\build.make gdtoa/CMakeFiles/qnan.dir/depend
mingw32-make[2]: Entering directory 'C:/DEV/msys32/g33mgw/release'
Generating arith.h
cd /d C:\DEV\msys32\g33mgw\release\gdtoa && .\arithchk.exe >C:/DEV/msys32/g33mgw/release/gdtoa/arith.h
mingw32-make[2]: Leaving directory 'C:/DEV/msys32/g33mgw/release'
mingw32-make[1]: Leaving directory 'C:/DEV/msys32/g33mgw/release'

mingw32-make[2]: *** [gdtoa\CMakeFiles\qnan.dir\build.make:61: gdtoa/arith.h] Error 295720572
mingw32-make[2]: *** Deleting file 'gdtoa/arith.h'
mingw32-make[1]: *** [CMakeFiles\Makefile2:780: gdtoa/CMakeFiles/qnan.dir/all] Error 2
mingw32-make: *** [Makefile:129: all] Error 2
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 »

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/com ... 5bc0481225
Fix here:
https://github.com/drfrag666/gzdoom/com ... 2bb3cd62fe

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.
So in the end i retire what i said and MinGW-w64 is not a POS. :mrgreen: It's lightweight and free and that's cool. MSYS2 is not needed.
Unfortunately with the recent refactoring i would need to update the fix, AFAIK the VC preprocessor is non conformant so probably it will not compile anymore on windows with any other compiler.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: fixing MinGW compilation

Post by Rachael »

No compiler that becomes popular is crap. And MinGW both 32 and 64 are good compilers.

They're just not the compilers I prefer to use for my work, at least not right now.
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 »

Like I said, the compilers themselves are not the problem, but the toolchains that are associated with them are suboptimal.
Do I need to say more than MSYS? Apparently it was more important to get full POSIX compatibility than full Windows support.
drfrag wrote: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/com ... 5bc0481225
Fix here:
https://github.com/drfrag666/gzdoom/com ... 2bb3cd62fe
If you post your fixes as PRs, you may actually have a chance to get them added.
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 »

Fortunately MSYS is not needed and the environment can be set up very quickly. I'd need to reapply the patches after the refactoring is finished, i'd have been better to have MinGW fixed before that.
I could keep it working if i'm still around or may be Blzut3 could help when he comes back.
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 »

Why would being a position-independent executable break it? Especially since it seems it was explicitly turned on, if it needs to be turned off for a non-broken build it sounds like an issue elsewhere.
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 »

No idea but with tmd-gcc i got the following warning: -fPIC ignored for target (all code is position independent).

https://stackoverflow.com/questions/313 ... ndent-code
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 »

Chris wrote:Why would being a position-independent executable break it?

Probably because the compiler creates broken code when the setting is on.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: fixing MinGW compilation

Post by _mental_ »

drfrag wrote:the fPIE flag added recently for linux broke the MinGW-w64 executables
No, it's a broken compiler that does not support such important feature properly. This is especially true for x64 where you can get it for free.
ASLR was not invented yesterday, it's been around for 15 years at least. No surprise that companies are still using "non-standard and buggy" MSVC exclusively.
A warning about enabled PIC when it was explicitly requested is really pointless too.
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 »

That depends on how you look at it, compiler bug or not that flag broke MinGW-w64 executables. The ticket has been closed as not a bug. :?:
I've read somewhere:
The -pie option is largely ignored on Windows targets. It tells the linker to create relocations for executables (.EXE). Normally executables on Windows aren't relocatable, the relocations allow it be relocated like a DLL.
With Windows, the code is patched at run time for relocation purposes. In the Linux and Unix worlds, this technique is known as text relocation. With Linux, ASLR is achieved in a different way. Rather than patching the code at runtime, the code is compiled in a way that makes it position independent. That is, it can be loaded at any memory address and still function properly.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: fixing MinGW compilation

Post by _mental_ »

The first statement is false nowadays. By looking at process list on my Windows 10 system I found only one executable without ASLR (it was built by Delphi).
Both statements are explaining implementation details while I'm evaluating any feature like a binary function, it either works or it is broken.

Why does PIC/PIE in GCC work in other OSes like Linux, BSD, macOS? Windows has supports ASLR for many years.
It seems it's not supported by particular GCC fork just because developer(s) didn't implement this feature for some reason.
Then it's not a limitation of Windows.

In any case, if enabling any compiler/linker flag produces knowingly broken executable, it's a bug of that toolchain.
At least, report an error and exit with non-zero code when something isn't implemented.
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 »

The first statement was about gcc on windows. If the option is not ignored in their implementation i guess it could work in some special cases.
According to the second one ASLR works in a different way on windows.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: fixing MinGW compilation

Post by _mental_ »

So what? If ASLR works differently, let's silently break executable files, right?

You are missing the point. I'm not asking why it's broken.
I'm saying that it should be fixed in toolchain, not in software built with it.

It's not a big deal if custom built GZDoom executable has no ASLR support. It's OK as a workaround.
But think about software that requires as much secure settings as possible, like a web browser.
What's proposed to overcome non-functional PIC/PIE executable? To disable this feature and let software be exploited easier.
Most likely developers of affected software will replace such toolchain with something better.
Post Reply

Return to “General”