0003598: Change Windows compiler

Notes
(0020320) Blzut3 (administrator) 2019-01-26 09:03	Quote from Zalewa We might even get Win98 support back. You won't. Not only does Qt5 not support it rendering the idea moot, but MinGW-w64 is not MinGW. w64 is XP+. (The original MinGW is updated and does target 98, but I highly doubt Qt5 works on anything below XP.) Possibly worth noting that Clang for Windows is a thing. I haven't personally used it so no idea if it has any benefits over MinGW-w64, but just wanted to throw that out there. Not sure if it's true but I've heard that Clang doesn't have the mess with exception compatibility that MinGW does. Quote from Zalewa (ie. no 'xp' version at all, or something). Visual Studio 2019 does not support XP anymore.

(0020382) Zalewa (developer) 2019-02-11 21:48	Just wasted an hour on Qt 5.12.1 trying to fix linking problems only to finally figure out that this version only has support for 64-bit compilation in MinGW. Seems that I'd either have to, in order of preference, stick to 5.11.3, 5.7.1 (which I already have installed) or compile 5.12.1 by myself. CMakeLists.txt will need some fixes to support MinGW again. The command that generates windows.o from windows.rc is not up-to-date, but this should be easy to fix. I can't tell if there will be anything else before I get the code to link properly. Anyway, I made a small progress today.

(0020386) Zalewa (developer) 2019-02-12 20:47 edited on: 2019-02-12 20:50	The immediate compilation & linking problems are fixed by this commit. MinGW-w64 tools: - MinGW-w64 build: i686-8.1.0-release-posix-dwarf-rt_v6-rev0.7z - Qt 5.11.3 offline installer (2.5 GB): qt-opensource-windows-x86-5.11.3.exe - Qt 5.7.1 offline installer (1.1 GB): qt-opensource-windows-x86-mingw530-5.7.1.exe Remarks so far: - MinGW-w64 build with Qt 5.11.3 doesn't work in Windows XP. - MinGW-w64 build with Qt 5.7.1 works just fine in Windows XP. - Binaries produced by MinGW-w64 are somewhat larger. So are the Qt libs for this compiler. The whole package is now 7.5 MB larger than the MSVC build (25 MB -> 32.5 MB). This is after I've stripped the .exe and all our .dll files. Without strip there's an additional 2.5 MB overhead. According to what people say on the Internet, this size increase is something that we'll have to live with. MSVC builds are smaller because the CRT code is in the MSVC runtime DLLs, while MinGW incorporates the same code into the built binaries. I would prefer to keep the Windows XP support so I think that we should stick to Qt 5.7.1 for the time being. TODO: - Add a call to 'strip.exe' to the install procedure somewhere. - Add libgcc_s_dw2-1.dll, libstdc++-6.dll and libwinpthread-1.dll to the install procedure. - Change the update packages to accomodate for different runtime DLLs and the new Qt distribution. In regards to clang/llvm: the official build for Windows compiles binaries the MSVC way, which means it comes with the same 41 DLL Mordor as the v140_xp toolset. I've read it's possible to make the compiler work the MinGW way but only if I take its source code and compile it with MinGW. I didn't check if there are any unofficial MinGW clang builds available and I also didn't delve into compiling it on my own, yet.

(0020402) Zalewa (developer) 2019-02-17 13:40	I think we should now be ready to switch the compiler. Here's a list of relevant commits in addition to the one already mentioned in the previous comment: - Package MinGW runtime libs in the "install" target + a direct ammendment of that commit. - When packaging a MinGW build for the auto-updater, use "install/strip" target instead of "install". - On a separate branch: Update auto-updater package definitions and compilation instructions for Windows. I will merge this separate branch into default if no immediate problems are found. The auto-updater will need to provide updates for all packages as nothing will be compatible. Additionally, I've managed to get Clang to compile executables that use the MinGW-w64 runtime. To do that, I first needed to compile Clang with MinGW-w64 by myself. It was simple. However, Doomseeker compiled with Clang 7.0.0 crashed when loading the plugin DLLs. The reasons for this are explained here and boil down to binutils assuming alignment of 4 in .o files whereas Clang 7.0.0 doesn't care about that. The problem was fixed in binutils in late 2018, so I assume that my MinGW-w64 from May 2018 doesn't have the necessary fix. Anyway, I fixed the crash by using Clang 6.0.0. I then compared performance of each compiler by timing sorting of a fully refreshed server table. Conclusions: - The timing test indicates that GCC/Clang builds are twice as fast than MSVC v120_xp despite producing larger binaries. - There's no difference between GCC and Clang in regards to performance. - There's some difference between GCC and Clang with stripped binaries in regards to size, but ultimately the results vary. Some DLLs were smaller with GCC, some with Clang. In the end, the Clang package is about 100KB smaller which is about a 0.25% size reduction from the GCC build. - Clang and GCC builds are indeed ABI-compatible. Given all of this, I don't think there's any reason to bother with Clang in this setup. It only adds extra problems. gcc compiler bundled with MinGW-w64 is good enough.

(0020403) Pol M (developer) 2019-02-17 19:37	I've been able to cross-compile doomseeker from my arch machine, but I've made some minor modifications related to .rc files since currently in some cases we manually compile them instead of letting cmake handle this. commit Obviously, it runs quite poorly under wine, and the updater seems to get stuck installing the updates. Also, if someone wants to also reproduce this, you'll have to make some tweaks in your machine.

(0020404) Zalewa (developer) 2019-02-17 20:26	Pol, I added your commit to the main repository as it's a clear improvement.

(0020408) Pol M (developer) 2019-02-17 21:07	Nice :)

(0020417) Blzut3 (administrator) 2019-02-18 22:31 edited on: 2019-02-18 22:31	Sounds/looks good to me. About the only comment I have is if we're sticking to a previous release of Qt for now shouldn't you test 5.9 given that it's an LTS? Probably doesn't matter much since we'll likely inevitably be compiling our own Qt but I guess that depends on how quickly they hard drop XP. In regards to the RC thing, when I was cleaning up ECWolf's mingw support I also noticed that CMake started supporting rc files with MinGW a LONG time ago. There's probably a lot more that can be cleaned up, but waiting for the Ubuntu 14.04 LTS to go EOL so we can bump to CMake 3.5 and take advantage of most of the wonderful modern CMake patterns.

(0020418) Zalewa (developer) 2019-02-18 22:34	I will try 5.9, but the documentation states that the final version that supports WinXP is 5.6. For some reason 5.7 also works, but I wouldn't expect that from 5.9.

(0020424) Zalewa (developer) 2019-02-21 17:12 edited on: 2019-02-21 17:13	Qt 5.9 doesn't work in WinXP as it fails on missing CancelIoEx which was added in Vista. We'll have to stick to 5.7 for Windows.

(0020426) Zalewa (developer) 2019-02-24 14:53	I merged the mingw-w64 branch into default, thus concluding the compiler change. Doomseeker for Windows will be built with MinGW-w64 from now on and we will finally be able to use the full potential of modern C++ standards.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	WubTheCaptain Pol M
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2019-01-26 08:40	Zalewa	New Issue
2019-01-26 08:40	Zalewa	Status	new => assigned
2019-01-26 08:40	Zalewa	Assigned To	=> Zalewa
2019-01-26 08:41	Zalewa	Description Updated	View Revisions
2019-01-26 08:41	Zalewa	Description Updated	View Revisions
2019-01-26 08:42	Zalewa	Description Updated	View Revisions
2019-01-26 09:03	Blzut3	Note Added: 0020320
2019-02-11 21:48	Zalewa	Note Added: 0020382
2019-02-12 20:47	Zalewa	Note Added: 0020386
2019-02-12 20:49	Zalewa	Note Edited: 0020386	View Revisions
2019-02-12 20:50	Zalewa	Note Edited: 0020386	View Revisions
2019-02-17 13:40	Zalewa	Note Added: 0020402
2019-02-17 13:40	Zalewa	Status	assigned => needs review
2019-02-17 19:37	Pol M	Note Added: 0020403
2019-02-17 20:26	Zalewa	Note Added: 0020404
2019-02-17 21:07	Pol M	Note Added: 0020408
2019-02-18 22:31	Blzut3	Note Added: 0020417
2019-02-18 22:31	Blzut3	Note Edited: 0020417	View Revisions
2019-02-18 22:34	Zalewa	Note Added: 0020418
2019-02-21 17:12	Zalewa	Note Added: 0020424
2019-02-21 17:13	Zalewa	Note Edited: 0020424	View Revisions
2019-02-24 14:53	Zalewa	Note Added: 0020426
2019-02-24 14:53	Zalewa	Status	needs review => resolved
2019-02-24 14:53	Zalewa	Fixed in Version	=> 1.3
2019-02-24 14:53	Zalewa	Resolution	open => fixed
2019-07-30 10:13	WubTheCaptain	Status	resolved => closed
2020-06-07 02:32	WubTheCaptain	Relationship added	related to 0003803
2020-06-07 02:36	WubTheCaptain	Relationship added	related to 0003804