User forums > General (but related to Code::Blocks)
Changing MinGW compiler, which ships with C::B
eXpl0it3r:
Let's try this one more time, shall we? ;D
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:
--- Quote from: stahta01 on October 13, 2014, 09:01:48 pm ---Edit: I think your suggestion is no good because you do NOT know what you suggested. You posted links to two different places!!
--- End quote ---
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...
--- Quote from: stahta01 on October 13, 2014, 09:01:48 pm ---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.
--- End quote ---
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:
--- Quote from: eXpl0it3r on October 13, 2014, 10:11:28 pm ---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.
--- End quote ---
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.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! :-* ;D
edison:
If my memory is correctly, the dw2 posix version TDM-GCC will use dyna link as default.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version