Which MinGW GCC to target?

BlitzMax Forums/Brucey's Modules/Which MinGW GCC to target?

Brucey(Posted 2015) [#1]
So, as some of you noticed with the recent wxMax release (which was built on GCC 4.8.x), there were issues with both GCC 4.7.x and 4.9.x.

The 4.7 bug should be easy enough to rectify, but the 4.9 problem requires some larger changes to the code - and it seems other modules will require patching to work with 4.9 too.

I am happy to push everything to build against 4.9 but there is a concern that older versions of GCC may have issues that need fixed or may not even work at all with the updated code.

Is it fair to push people who want to use my modules onto the later/latest versions of a compiler, or should I try to handle builds for a wider spread of versions?

I suppose I could add notes where appropriate, along the lines of, "Requires minimum GCC xxxx" ?

:o)


xlsior(Posted 2015) [#2]
Of course a wider variety of version it works on is nice, but you probably have to choose your battles -- trying to support multiple versions is likely going to lead to some mods staying broken on different versions for long times since it's difficult/impractical to fix them -- a single recommended/supported version would prevent that from happening.

And if you need to make special modifications -anyway-, perhaps the best version to pick would be the latest and greatest (4.9) , rather than settling for one that's already been superseded...

But no matter which version(s) you pick there's likely always going to be SOME issues due to other developers module potentially having their own requirements -- but you can't please everyone all the time. :-?

Bottom line: "Choose your battles".


(By the way, somewhat unrelated: Since you've been working on 64-bit support through NG, are any of your other non-stock modules compatible with 64-bit builds? e.g. bah.regex -- it compiles, but can it be trusted on a 64-bit machine or is there still a risk of it blowing up if the executable happens to get loaded in a >4GB memory address? Do you happen to have a list of modules that you know work OK in 64-bit, or ones you know for sure don't?)


Derron(Posted 2015) [#3]
As I had to use another MinGW for "wx.mod" than for "maxmod2.mod" it wont differ much .. but hmm, I am using "libxml.mod" and "persistence.mod" together with "maxmod2.mod".
As both seem to do their job as "Non-module" for now, I do not think that it will break things on my side if you push them all to one common denominator - eg. 4.9.x.

Like xlsior already mentioned: the best thing is if it removes the workload from you. If support of multiple compilers would be easy going people could backport things on their own (and provide the backports for specific "stable" releases - of course it helps if one assists them in creating the ports, or "guide" them).

In short: support one compiler (eg. 4.9.x).


bye
Ron


Ole JR(Posted 2015) [#4]
Me think that somewhere down the line an update to 4.9.x might come anyway?
But pick one, and go for that one only.

Now if I could get vanilla bmx to compile with something newer than 4.7.x..
Can't for my life remember what I did to get it working last install (ie before disk crash)..

Getting some undefined reference to `pthread_mutex_lock' and so on now,
and yes I'm using latest bmk-ng, but it somehow try to use ld.exe to link.
And that's not right.. Is it?


Brucey(Posted 2015) [#5]
Getting some undefined reference to `pthread_mutex_lock' and so on now

Probably requires a link to libwinpthread, or something like that.

The latest versions of MinGW have support for pthreads, and requires you to link in a static library as part of the build.

I've currently got this check :
			' if using mingw64, we need to link to pthreads
			If processor.HasTarget("x86_64") And processor.BCCVersion() <> "BlitzMax" Then
				files :+ " -lwinpthread "
			End If

but perhaps I can drop the check for the new bcc and just add this in regardless.
Note: This HasTarget is true if you are building with the 64-bit TDM (which also supports building 32-bit apps). I make the assumption that you will be using this version if you are working on bmx ng. ;-)


Ole JR(Posted 2015) [#6]
Yes I will absolutely use bmx-ng as most of what I do is either wx or console.
So.. What you are saying is that I can remove the "old" 32 bit onlu MinGW when I use your bmk-ng?


Brucey(Posted 2015) [#7]
... most of what I do is either wx or console

What!? No games? :-p


Brucey(Posted 2015) [#8]
I've now set bmk_ng (in the latest version) to link to pthreads on Win32 for the version of GCC >= 4.8

I imagine someone with such a version will find that this is now an issue for them... but we'll see how it goes!

What you are saying is that I can remove the "old" 32 bit onlu MinGW when I use your bmk-ng?

No, it should still work. If you have any other issues with it, let me know and I can tweak the settings some more.


Ole JR(Posted 2015) [#9]
Quick test compiling firepaint (threaded) now works on win8, tdm(32)-4.8.1 with old/vanilla bmx.
Switching to tdm64 also works, but fail bad on building modules.
That's no issue, just keeping c:\MinGW as 32bit/vanilla,
and have the MinGW32 (64bit) in the BMX-NG folder.
(bmx-vanilla/legacy: wxrarinputstream.mod still doesn't build tho as stated in another thread)


GW(Posted 2015) [#10]
Slightly OT:
Brucey, Have you considered a binary release of NG that comes with the required mingw in a subdir and references that one explicitly? (that's how Nim and some other languages do it)
A few months back I built bmx-NG and got it working, but it was F**ing nightmare. ultimately, it created so many conflicts with my normal Bmax/Mingw setup that I had to get rid of it. Like me, I think more people would like to contribute to testing, but it needs to easier to setup, get running and be a little more isolated.


Derron(Posted 2015) [#11]
You get it running even with the demo version of blitzmax - as it just uses bmx-stuff.

with the bcc you then compile the modules.

But Brucey will surely be able to tell you more.


Edit: if you want to add to the instructions:
https://github.com/bmx-ng/bcc/issues/76

bye
Ron


Brucey(Posted 2015) [#12]
If you know what you're doing, it's easy enough. But if you don't know what bits should go where, then it's easy to mess it up too :-)

Anyway, as skid mentioned in another thread, given its "still in development" status, it's more for advanced users at the moment - those who don't mind hacking things around and expecting it not to work :-)


skidracer(Posted 2015) [#13]
Brucey, I would consider making MSVC official tool chain for Windows.

There are good reasons why most large open source projects use it for win32 distributions as it is fast and stable (and produces binaries compatible with C++ API such as steam which is I suppose a little irrelevant).


Brucey(Posted 2015) [#14]
I suppose it is something to consider.

What are the *disadvantages* to using MSVC - apart from the obvious like having to completely rewrite chunks of code that expect GCC?


skidracer(Posted 2015) [#15]
I was using MSVC during development of BlitzMax with a modified bmk. From memory (and it is some years ago) it was trivial to add support and I would guess you will have less issues than those mentioned in this thread because nearly all open source software I have ever seen supports the compiler.

In fact I think in many places MinGW is seen as a bit of joke as it has some truly bizarre performance issues as though it was using chunks of cygwin to perform all it's IO when compiling. And then there is the problem that the rest / a lot of the world has left GCC behind in favor of LLVM.


skidracer(Posted 2015) [#16]
I am searching my archives....


Henri(Posted 2015) [#17]
Hi,

just wandering are we talking about bmk-ng or modules in general ? With bmg-ng there are bound to be similar issues regardless of the chosen compiler/chain sense distribution is in source format. If distribution would be in already binary format then those issues would of course be diminished.


@MinGW version:

TDM gcc 4.71 has been thus far considered quite stable release (e.g it is Codeblocks preferred version), but lot of optimizations have been introduced in newest versions so in that regard I would probably choose 4.9.2 as it's likely to be latest version before 5.0 .

-Henri


LT(Posted 2015) [#18]
Isn't MSVC rather costly?


Ole JR(Posted 2015) [#19]
Isn't MSVC rather costly?

Visual Studio express/comunity is free..

I (hope) this is what the talk is about :-)