|Anonymous | Login | Signup for a new account||2020-09-19 22:04 UTC|
|My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003598||Doomseeker||[All Projects] Suggestion||public||2019-01-26 08:40||2020-06-07 02:36|
|Target Version||1.3||Fixed in Version||1.3|
|Summary||0003598: Change Windows compiler|
|Description||The current compiler for Doomseeker for the Windows platform is MSVC with v120_xp toolset. This has started to cause compatibility issues: |
- Very limited support for C++11 standard and beyond.
- No Windows 98 support.
As we would like to utilize C++11 and beyond for the greater good we need to change the compiler. However, simply updating the MSVC toolset may not be the best idea. While v140_xp already improves on C++11 support, it also needs to include 41 DLLs in the distribution (see it for yourself). We would either need to include those 41 DLLs with Doomseeker, or require people to install the MSVC redist.
I'm unaware if there are any other MSVC toolsets available right now, but I wouldn't be surprised to learn that the trend will get even worse (ie. no 'xp' version at all, or something).
The sanest way to go seems to be to return to MinGW.
The current version of MinGW is quite modern and should support anything we throw at it - it's Windows port of GCC, after all. While some more investigation is needed, AFAIK it supports Windows XP without having to jump through any special hoops. We might even get Win98 support back.
|Additional Information||See the discussion here:|
Quote from Zalewa
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
Visual Studio 2019 does not support XP anymore.
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.
edited on: 2019-02-12 20:50
The immediate compilation & linking problems are fixed by this commit.
- 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.
- 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.
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.
Pol M (developer)
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.
|Pol, I added your commit to the main repository as it's a clear improvement.|
Pol M (developer)
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.
|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.|
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.
|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.|
|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|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2020 MantisBT Team|