Changing MinGW compiler, which ships with C::B

[eXpl0it3r]

Let's try this one more time, shall we?

The TDM builds had its right place back when MinGW was still the main thing and not that many people were creating builds of the MinGW-w64 project. Nowadays however nearly everyone has dropped the original MinGW builds (no horrible install process anymore) and there are a number of different builds for the MinGW-w64 project. I solely mention this, because that seems to have been the main argument for choosing the TDM builds so far.
I know TDragon is part of this community and appreciate all his work, but for the sake of an objective discussion, could we please put personal matters aside and look at it technically?

So in case you didn't read the discussion above, here's again the problem space:

• The TDM builds link by default statically against the runtime library. The compiler will generate an error when using the common -static linker flag. And if one really, really wants to build something dynamically against any MinGW/GCC compiler out there, one has to specify -shared-xyz.
• As a consequence of this uncommon behavior, every build script design for a GCC compiler out there is simply broken, unless it introduces specific configuration routines for the TDM builds. Just hold in for a moment here and think about the numbers of build scripts that are out there targeted for standard behaving GCC compilers. Is this really something one can just ignore?
• And then I can already here you "all" say in canon: "Use a different compiler then, if you don't like it!!1" That's exactly the third issue. Those who say that, don't seem to understand that Code::Blocks is one of the most popular non-Visual Studio IDE on Windows! By providing a compiler side by side, you're effectively introduce a default compiler. Do you know how much Google is paying Firefox to have Google as their default search engine? Do you know why they would pay that much? It's because people are lazy and when they get something by default, they are going to use it. Thus by shipping the TDM builds with Code::Blocks, you're effectively making the TDM builds one of the most used compilers on Windows and herein lies the problem, the most used compiler, which is advertised as MinGW compiler, meaning GCC, is broken at its core.

If you've never had an issue building something, then well you're lucky or haven't build (m)any libraries.
TDragon's argument about the licensing issue might be true (I'm not a lawyer so who knows), but just because of that breaking standard behavior is simply not something I can accept.
If you'd ask me, I'd suggest you should start using the MinGW Builds. They provide a clean installer (similar to what TDragon has done), they provide all the setting choices you could want (Posix vs Win32, DW2 vs SJLJ vs SEH, x86 vs x64) are always uptodate with upstream (GCC 4.9.1r1 as of writing) and have worked with any build script I've thrown at it so far, thus standard GCC conforming.
Also if you want to see practical examples of TDM failing, just let me know - there are plenty.

It would be really nice, if we could get an objective discussion going in here. My last attempt only raise a few voices and non of the arguments provided hold any ground (anymore).

[stahta01]

eXpl0it3r:

Do they (MinGW Builds) test building wxWidgets?

Because TDM does; and, I think this is likely a good requirement for the MinGW GCC toolchain bundled with Code::Blocks.

Edit: I think your suggestion is no good because you do NOT know what you suggested. You posted links to two different places!!

Tim S.
 

[eXpl0it3r]

Edit: I think your suggestion is no good because you do NOT know what you suggested. You posted links to two different places!!

Please tell me you're joking, please, please...
I do know exactly, what I'm talking about. The first link points to the download page of the MinGW-w64 project, which features next to other builds the "MinGW Builds". The second link points directly to the installer of the "MinGW Builds" which is located in the MinGW-w64 SourceForge project. IF you're talking about the fact that there's a dedicated "MinGW Builds" project on SourceForge, guess what they've moved to the MinGW-w64 project and the builds on the MinGW Builds project are outdated. I really, really hope this was some sort of a joke...

Do they (MinGW Builds) test building wxWidgets?

Because TDM does; and, I think this is likely a good requirement for the MinGW GCC toolchain bundled with Code::Blocks.

So you're suggesting that the TDM builds should be prefered because they check if a third-party library gets tested by the compiler builder? I'm aware that Code::Blocks is heavily depending on wxWidgets, but having the "requirement" that the compiler builder has to test a third-party library, is just seriously ridiculous. If wxWidgets can't be built with a standard conforming compiler, such as one from the MinGW Builds, then they might want to fix their code base.
If I were to only choose compiler builds for which the author did test all the libraries I imagine to use, then I'd never find a compiler...

Of course if all it takes is testing whether wxWidgets builds with a different compiler than TDM, by all means let me test it. wxWidgest is currently build with the MinGW Builds Posix Dwarf2 4.9.1r1 x86. However if you've ever built wxWidgets, you know it will take a while till it's finished, but rest assure, I'll post the binaries as soon as they been built - it's really not that hard.

Edit: Well there are tons and tons of options, but with the "default" --enable-monolithic --enable-unicode it built just fine: wxWidgets2 [7.85 MiB]

[oBFusCATed]

If wxWidget can't be built with a standard conforming compiler, such as one from the MinGW Builds, then they might want to fix their code base.

I hope you know that the C++ standard doesn't mention libraries nor command line flags and leaves them to the implementation!

Also I don't know why is this aggressive behaviour, why don't you just mention on your site that you don't support TDM and be done with it?

p.s. I don't really care what we ship as default compiler on windows as I don't use it 
p.p.s. I hope I won't see you in a 2-3-4 years starting a topic how we should drop TDM/MinGW in favour of clang! 

[edison]

If my memory is correctly, the dw2 posix version TDM-GCC will use dyna link as default.

[eXpl0it3r]

I hope you know that the C++ standard doesn't mention libraries nor command line flags and leaves them to the implementation!

I obviously wasn't talking about the C++ standard, but rather standard behavior for GCC compilers.

Also I don't know why is this aggressive behaviour, why don't you just mention on your site that you don't support TDM and be done with it?

See my point above about "setting defaults".

p.p.s. I hope I won't see you in a 2-3-4 years starting a topic how we should drop TDM/MinGW in favour of clang!  

I don't see why I shouldn't.

If my memory is correctly, the dw2 posix version TDM-GCC will use dyna link as default.

Even if it does, Code::Blocks doesn't ship DW2 POSIX version, thus it doesn't matter. Again the point is, Code::Blocks is setting a "default" compiler by shipping the TDM builds and that "default" compiler is broken. Anyone should be able to use TDM if they really want, I just talk about changing the compiler that gets shipped with Code::Blocks.

[oBFusCATed]

I obviously wasn't talking about the C++ standard, but rather standard behavior for GCC compilers.

I really doubt there is such thing as standard, also as far as I know these options you're talking about are relatively new additions to GCC.

p.p.s. I hope I won't see you in a 2-3-4 years starting a topic how we should drop TDM/MinGW in favour of clang!  

I don't see why I shouldn't.

Because this won't help C::B to become better.

As I've said why don't you just state that you don't support TDM and be done with it?
Close any ticket related to it with invalid and go on.

[eXpl0it3r]

I really doubt there is such thing as standard, also as far as I know these options you're talking about are relatively new additions to GCC.

If you're caught up too much with the word "standard", then I might have to defuse it to "default behavior" or "how ever other GCC version in existence works".
Whether they are new or old doesn't matter.

As I've said why don't you just state that you don't support TDM and be done with it?
Close any ticket related to it with invalid and go on.

Because I want to solve the issue at its root rather than just switching to "ignore mode". Again read the bit about setting a default compiler from above. This issue doesn't just touch my projects, it affects every project out there.

If you don't care what compiler gets shipped, why don't you even want to think about a change?

Again all the arguments about "use something else" or "ignore it" etc. are not actual solutions to the problem I'm presenting here. It's not just about my personal projects and the ones I'm involved with, but it's about Code::Blocks setting a default compiler for a lot of users without realizing and without admitting that their shipped compiler has major flaws.

[TDragon]

The compiler will generate an error when using the common -static linker flag.

Could you provide some more information about this specific problem by any chance? It's not something I've ever been made aware of, and I'd like to see if it's something I could fix. I'd be very grateful for a bug report at the TDM-GCC tracker (preventing off-topic discussion here).

Also, in the intervening time since we last conversed, TDM-GCC has changed to allow the "-static-libgcc" and "-static-libstdc++" flags as no-ops. I'm not sure if this answers your objection to the default static linkage or not, but I figured it was worth a mention.

-John E. / TDM