MinGW-w64 and it's next release......

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
After my foray into the adventures with Clang and Cerberus. I decided with the current state of the compiler tools chains that clang relies on, that it was not worth the hassle of adding another layer of tool chains into the mix with all the problems it brings. Clang requires the latest version of MinGW, which isn't available through the normal downloads. And depending on the version of Visual Studio use are using, it requires the latest version of Clang. i.e VS2017>Clang7+, VS2019>Clang8+

Now it wouldn't be such a problem as long as Cerberus was just using Visual Studio, but as CerberusX is based off MonkeyX and the latter ended up making MinGW as it's default, which would make a few not happy if MinGW support was dropped. But I though I would have a look at the MinGW-w64 forums to see if anyone had asked when the next release was due. As it turned out, somebody did. And I got the impression that it would be a very long wait before any new release was available as a download.

At some point in the future the current available downloads of MinGW-w64 will cause issues. The TDM-64 compilers create 32 bit GLFW applications that already has one known issue with crashing. And without any new compiler updates that are easy to install, it will make Cerberus less appealing for desktop games.

This then would as I see it, leaves three choices:
  1. Instructions are given to install MSYS2 and how to set up. MSYS2 is a uninx like shell environment and like ArchLinux uses a 'rolling release'. That is to say that that every update will download the latest packages. As of today, MinGW is at version 9.1.0.
  2. An up to date MinGW built from the current sources is either distributed with CX, or made available as a download. This can take a fair amount of time to do and isn't as simple as it sounds. Though build via MSYS2 would make it a bit easier.
  3. MinGW support is removed.
Opinions?
 
Last edited:

MikeHart

Administrator
Staff member
Joined
Jun 19, 2017
Location
Germany
I would rather like to drop the MingW support on Windows because MsVC compiles much faster.
The optimal thing would be having one toolchain that ships with CX and is installed without the user needing to going through loops and hoops.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
I would rather like to drop the MingW support on Windows because MsVC compiles much faster.
Yep. It's faster and I didn't notice any real speed increase with the use of clang with either VS or MinGW. And as I've said before, [Visual Studio] it makes dealing with maintaining CX much simpler if there is only the one compiler tool chain to contend with on Windows.

The optimal thing would be having one toolchain that ships with CX and is installed without the user needing to going through loops and hoops.
That would lead back to the discussion of a new transcc directly outputting either LLVM IR or pure x86 Assembly.

Having a one fits all would lead to something like GLBasic being distributed. Where there is a minimal distribution and additional platforms are bolted on containing prebuilt libraries and specifically tailored tool chains possibly relying on cygwin/msys2 libraries to build on Windows or the native shell on Linux and MacOS. Compile times would be fast, but making any change to a module would require a rebuild. This would be doable, but transcc would of course need a complete rewrite to change how it works. And then there could be possible licence issues with distributing parts of cygwin, msys2, Android SDK, MacOS/iOS SDK.

The plus side of a GLBasic like environment.
  • Faster compile times.
  • Less messing around getting everything installed for the end user with them only having to unzip a file and add it to the targets directory.
The down side of a GLBasic like environment.
  • Developer maintenance would increase with having to deal with the additional tool chains for each platform; especially for those targets such as Android, OSX and iOS.
  • Each platform that CX is to run on would require it's own versions of those tool chains.
    • This is more than likely why there isn't a MacOS or Linux version of GLBasic.
    • Different tool chains are not such a problem with if everything is using MinGW when on Windows and targeting Windows on Linux and MacOS X.
  • Changes to modules would need to be recompiled.
  • Possible licence issues.

The current set up puts the end user having to install the tool chains, while the developers has to try to keep up with any changes to those tool chains.

May be it's time for a poll on MinGW?
 
Last edited:

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
I dont know anything about them so i did a quick search and this guy seems to like msvc for its ease of setting up i guess down side is slower compile time unless implemented right
Actually as long as you know which MinGW compiler you want from the downloads, which means you need to understand the exception handling and threading model it uses. Knowing the exception handling determines whether you can only build 32 or 64 bit binaries or both.
Installing is just a case of:
Donwload zip file, extract and add path_to\MinGW32\bin or path_to\MinGW64\bin to the system path
Write a makefile and pass it to mingw-w64-make or call g++/gcc directly.

Where as Visual Studio is:
Download installer
Select select the default C++ stuff
Fine tune the above selecting individual components
Make sure that there is adequate hard drive space for the lot to download before installing as the default is to keep a backup.
Use either Visual Studio IDE, one of the console launchers to set up a build environment or locate MSBuild and add it to the shell system path and use a Visual Solution project file.

As for speed of compiling, MinGW is slow and DirectX support may not be up to the job if you choose to use it. And linking to libraries can be fun.
Where as MS tools are specifically written for use with their operating systems. MinGW is basically a hack of Unix GCC to get it working with Windows.
 

SLotman

Member
Joined
Jul 3, 2017
MsVC compiles much faster.
Really?

I could swear that here MinGW is much faster, but I never timed anhything. And after the first time compiled, both are fast and I don't see any difference (note: I'm still using the latest Monkey-X, and VS2012 to compile stuff)
 

RaspberryDJ

Member
Joined
Jun 3, 2019
Does this problem of compiling 64-bit affect Android or iOS as well?

I'm asking because I'm thinking of trying out Cerberus for an app next month.
Can you use Cerberus to compile a modern Android app and sell in their store?
Or is Cerberus in need of being fixed?

If Android is broken, is it possible to compile at least for the iOS store?
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Does this problem of compiling 64-bit affect Android or iOS as well?
MinGW, MinGW-w64 or TDM GCC MinGW has nothing to do with Android or iOS.
It's strictly a Windows desktop compiler, though with the right knowledge can be built as a cross compiler to output code that can run on other CPU architectures.

I'm asking because I'm thinking of trying out Cerberus for an app next month.
Can you use Cerberus to compile a modern Android app and sell in their store?
Or is Cerberus in need of being fixed?

If Android is broken, is it possible to compile at least for the iOS store?
The current binary download may be in need of an updated for Android. See the Android Target and iOS Target section for any changes and information.
 
Last edited:

Phil7

Active Member
3rd Party Tool Dev
Joined
Jun 26, 2017
2. An up to date MinGW built from the current sources is either distributed with CX, or made available as a download. This can take a fair amount of time to do and isn't as simple as it sounds. Though build via MSYS2 would make it a bit easier.
The optimal thing would be having one toolchain that ships with CX and is installed without the user needing to going through loops and hoops.
As allways I am comimg frorm a beginners/non professional point of view:
CX should work with at least html5 and desktop target out of the box. To me this is the minimal setup for simple testing and sharing.
If we can make the installation of MSVC a breeze, then I am with you droping MInGW. One of @dawlane 's testing binaries worked for me just having an all default installation of MSVX 2017 Community Edition.
Otherwise I would prefer a MinGW installation shiped with the CX installation, like MX2 does. With this "i686-6.2.0-posix-dwarf-rt_v5-rev1" I could build an executable for 32bit without that crashing issue, when clicking on the window frame. Maybe I am overlooking something here.


The other options of having a kind of custom tool chain would be to much effort on the developer side. There are so many things to do to make CX a success, I don't think it is realistic to put something on top of that.
Nevertheless I think this basic decission is really important to be made.

An up to date MinGW built from the current sources is either distributed with CX, or made available as a download. This can take a fair amount of time to do and isn't as simple as it sounds.
On the homepage of MinGW-W64 there are a listed a lot of projects using it. Could it be possible that they can provide a up to date version!?
Maybe this community could use some help of others that face the same problems.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
If we can make the installation of MSVC a breeze,
You can. Just distribute the MSVS web installer (if the licence permits) and pass command line options to download and install what you want. This means that the end user wouldn't have to install the Visual Studio themselves. A simple script could be used to do the task for a set up.

Otherwise I would prefer a MinGW installation shiped with the CX installation, like MX2 does. With this "i686-6.2.0-posix-dwarf-rt_v5-rev1" I could build an executable for 32bit without that crashing issue, when clicking on the window frame. Maybe I am overlooking something here.
And what about those users that do not want to use dwarf exceptions? Some may want to use only seh exceptions and 64 bit only. At some point Microsoft will tire of supporting legacy 32 bit applications and either cease to maintain the WoW64 sub system, or remove it as more software becomes 64 bit.

On the homepage of MinGW-W64 there are a listed a lot of projects using it. Could it be possible that they can provide a up to date version!?
Maybe this community could use some help of others that face the same problems.
So you are suggesting to ask or use a third party developer, who's own builds will more than likely be out dated, incomplete or incompatible. And besides, they may be only using MinGW-w64 and not necessarily building MinGW-w64. If you want a consistent MinGW compiler that will work with the current version of Cerberus, you have to build it yourself as it look like there will hardly ever be consistent releases from the MinGW-w64 developers. Most people use a Unix like environment such as CygWin or Msys on Windows, so they can use the build system as a result of most open source software being developed on Unix like systems. The rise and use of MSYS2 seems to be the reason that was given on the MinGW-w64 fourm as to why there wasn't any new release and so they are only concentrating maintaining code compatibility with the latest GCC version.
 
Last edited:

Phil7

Active Member
3rd Party Tool Dev
Joined
Jun 26, 2017
@dawlane Thanks for your answers. Very infomative and enlightning as allways! And definitely the politest way of telling me "No, nitwit." without mentioning any of those words. ;)

You can. Just distribute the MSVS web installer (if the licence permits) and pass command line options to download and install what you want.
So I am completely with you to drop MinGW then and something like a poll or more likely a thread to veto against the MSVS only solution would be nice.
I only can remember @Pierrou having problems running his worthwhile app, compiled with MSVS, on his machine.

Regarding that thread:
Could you summarize in short the main pros and cons of MinGW and MSVS as the opening post? Only to set the scope of what the discussion is about. No more than 10 lines of text.
As your preview versions of CX where the only ones that compiled at my machine whithout any issues, it would be great to have these as a testing base as a proof of concept in that thread.

It would be interessting what you all think about this!
 

Pierrou

Member
Joined
Jul 6, 2017
Hello
Indeed when compiling one of my apps for a Windows XP 32bit laptop we use at work I could only get the GW version working but sooner or later we will drop that old computer, and I still can run some kind of legacy version of CerberusX just to compile that one when needed. For everything else I'm using MSVC 2017 and it's fine.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Could you summarize in short the main pros and cons of MinGW and MSVS as the opening post?
Hard to do a short summary really. But I would end up with something like:
MINGW
  • Pro
    • It's open source
  • Con
    • It an ugly hack of GCC for Unix that has serious split personality issues.
VSVS
  • Pro
    • It's made for Windows applications.
    • One edition is almost free.
  • Con
    • It's made and maintained by Microsoft, need I say more.
:)

Here's my take on the pros and cons.
Others will have there own opinion on the subject.

MinGW vs MSVC 2017+

MinGW
  • Pros
    • Open source.
    • Can be included directly within the user or systems path variable to be directly invoked via the command line.
    • Later version include the newest C/C++ standards depending on the threading model.
    • Can get symbols directly from shared libraries to link against.
  • Cons
    • Licence restrictions apply on a number of tools and libraries.
    • Can have issues using .lib format libraries.
    • Requires knowledge of the types of MinGW compilers available, i.e. exception (dwarf2, seh and sjlj) and threading models (posix and win32). Note that the exception model also determines whether 32 bit or 64 bit binaries can be built and how exceptions are handled over libraries. SJLJ has issues with speed and DWARF2 has issues throwing exceptions through stack frames not compiled with dwarf2 (e.g. windows call backs).
    • There are speed penalties depending on the exception model.
    • You will need to have both a 32 bit and 64 bit compiler installed to created those types of binaries. This negates having MinGW in any system path variable. The TDM-64 offering was patched to switch between seh exception model for 64 bit and SJLJ exception model for 32 bit. But it's no longer being maintained.
    • SJLJ exception model doesn't look like it works correctly with the 64 bit version of Windows 10 and Cerberus.
    • You may be required to create custom .a files to link against in certain situations. This is not an easy task in some cases when dealing with MinGW 32 bit compilers.
    • Not always the latest version for download and you may be required to built it yourself if new C/C++ features are required.
    • A number of libraries my not be up to date and my cause unexpected behaviour.
    • Some MinGW compiler require their shared library run times to be distributed. You can avoid this, but requires some knowledge of how to link to libstdc++, libgcc and winpthread while avoiding including any other library that may be under a GPL/LGPL licence.
    • Mixing code compiled with different exception models can cause issues.
    • Compilation is slow.
MSVC 2017+
  • Pros
    • Guaranteed to work with MS Windows and never usually has any big issues.
    • Can build for both 32 and 64 bit version of Windows. Testing 64 bit applications will require a 64 bit version of Windows.
    • Multiple versions can be installed side by side. From VS2017 update 2 the command line tool vswhere can be used to probe for information about what's installed.
    • Usually fast compilation.
  • Cons
    • Some licence restrictions apply. Mostly depending on edition being used.
    • Cannot directly access the compilers without using one of the Visual Studio command line shells. You can use a VS project and use MSBuild directly or via putting the MSBuild location into the shells path variable.
    • Requires that the correct MS C++ run time is distributed with the application. Not usually a problem as the end user may already have that version installed.
    • Can be a pain to install if you do not know what you need. It is possible to use the Visual Studio web install tool via the command-line to pre-select and download the required components.
    • Not always up to date with C/C++ standards or they are only partially implemented.
    • Will complain about a number of CRT library functions being depreciated and not being safe. e.g. strcpy.
    • Cannot use MinGW .a files.
    • Requires .lib files to link against libraries.

Both compilers implement their own custom extensions that will of course be incompatible with each other. This means that a lot of additional pre-processor code needs to be included within the C/C++ files.
 

RaspberryDJ

Member
Joined
Jun 3, 2019
I see this thread talks about Clang and LLVM. Is this involved in macOS compilation? Or this thread strictly about Windows?
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
I see this thread talks about Clang and LLVM.
They are only mentioned as a result of a number of earlier topics elsewhere.
Is this involved in macOS compilation?
On MacOS XCodeBuild is used (Apples equivalent of MSBuild) , which in turn will use the version of Clang and LLVM maintained by Apple.
Or this thread strictly about Windows?
Yes it's strictly a Windows topic. Specifically about the MinGW compiler tool chain and if it should be dropped.
 
Last edited:
Top Bottom