TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)

[ironhead]

As with previous 4.3 builds, minor modifications were necessary in the C::B sources.

Are they significant modifications?

[stahta01]

As with previous 4.3 builds, minor modifications were necessary in the C::B sources.

Are they significant modifications?

No, just several minor ones. Here's three that had to be done a month ago; I have not tried it since then.

Tim S

Note: This is not a complete list of changes needed, but a good sample of how complex they are.

Code

Index: src/CodeBlocks.cbp
===================================================================
--- src/CodeBlocks.cbp	(revision 5083)
+++ src/CodeBlocks.cbp	(working copy)
@@ -384,7 +384,6 @@
 				<Option type="3" />
 				<Option compiler="gcc" />
 				<Compiler>
-					<Add option="-include sdk.h" />
 					<Add option="-DBUILDING_PLUGIN" />
 					<Add directory="include" />
 					<Add directory="include\scripting\include" />
Index: src/include/projectloader_hooks.h
===================================================================
--- src/include/projectloader_hooks.h	(revision 5106)
+++ src/include/projectloader_hooks.h	(working copy)
@@ -40,7 +40,7 @@
       * The isLoading argument is true if your hook is called when the project is being loaded,
       * and false when the project is saved.
       */
-    template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+    template<class T> class HookFunctor : public HookFunctorBase
     {
         public:
             typedef void (T::*Func)(cbProject*, TiXmlElement*, bool);
Index: src/include/editor_hooks.h
===================================================================
--- src/include/editor_hooks.h	(revision 5106)
+++ src/include/editor_hooks.h	(working copy)
@@ -40,7 +40,7 @@
       * The isLoading argument is true if your hook is called when the project is being loaded,
       * and false when the project is saved.
       */
-    template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+    template<class T> class HookFunctor : public HookFunctorBase
     {
         public:
             typedef void (T::*Func)(cbEditor*, wxScintillaEvent&);

[killerbot]

any reason why we would not apply this already today ?

[TDragon]

Are they significant modifications?

They are one-liner workarounds for GCC bugs, and are required in order to build C::B. I would not classify them as significant.

Here's three that had to be done a month ago; I have not tried it since then.

It hasn't changed; this is exactly what was necessary.

-John E. / TDM

[ironhead]

any reason why we would not apply this already today ?

Would be nice if they could be...  I'd like to avoid possible collisions when doing an SVN update. 

[stahta01]

This is an patch for MinGW GCC 4.3; note I have submitted an seconds patch to here
http://developer.berlios.de/patch/?func=detailpatch&patch_id=2559&group_id=5358
( The patch on berlios is an work around for an GCC bug in my opinion; and we should wait and see if it is fixed, before applying to C::B SVN.)

Tim S

This below is ready to be patched in the C::B SVN

Code

Index: src/plugins/contrib/help_plugin/help_common.cpp
===================================================================
--- src/plugins/contrib/help_plugin/help_common.cpp	(revision 5202)
+++ src/plugins/contrib/help_plugin/help_common.cpp	(working copy)
@@ -12,6 +12,7 @@
 #include <wx/intl.h>
 #include <wx/dynarray.h>
 #include <wx/textfile.h>
+#include <algorithm>
 
 
 using std::find;
Index: src/plugins/contrib/help_plugin/MANFrame.cpp
===================================================================
--- src/plugins/contrib/help_plugin/MANFrame.cpp	(revision 5202)
+++ src/plugins/contrib/help_plugin/MANFrame.cpp	(working copy)
@@ -10,6 +10,10 @@
 #include "MANFrame.h"
 #include "man2html.h"
 
+#include <sdk.h>
+#ifndef CB_PRECOMP
+    #include "globals.h" // cbC2U
+#endif
 #include <wx/sizer.h>
 #include <wx/dir.h>
 #include <wx/sstream.h>
@@ -20,10 +24,6 @@
 #include <bzlib.h>
 #include <zlib.h>
 
-#ifndef CB_PRECOMP
-    #include "globals.h" // cbC2U
-#endif
-
 namespace
 {
     int butSearchID = wxNewId();
Index: src/include/projectloader_hooks.h
===================================================================
--- src/include/projectloader_hooks.h	(revision 5202)
+++ src/include/projectloader_hooks.h	(working copy)
@@ -40,7 +40,7 @@
       * The isLoading argument is true if your hook is called when the project is being loaded,
       * and false when the project is saved.
       */
-    template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+    template<class T> class HookFunctor : public HookFunctorBase
     {
         public:
             typedef void (T::*Func)(cbProject*, TiXmlElement*, bool);
Index: src/include/editor_hooks.h
===================================================================
--- src/include/editor_hooks.h	(revision 5202)
+++ src/include/editor_hooks.h	(working copy)
@@ -40,7 +40,7 @@
       * The isLoading argument is true if your hook is called when the project is being loaded,
       * and false when the project is saved.
       */
-    template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+    template<class T> class HookFunctor : public HookFunctorBase
     {
         public:
             typedef void (T::*Func)(cbEditor*, wxScintillaEvent&);

[killerbot]

Tim,

I have applied the fixes.

On the other hand I myself prefer to remove the -include sdk.h from the cbp files.

Why ?

1) We should do includes like this :

Code

#include "sdk.h"
#ifndef CB_PRECOMP
#include headers from the sdk.h we actually need
#endif
#include all other headers we need who are not in sdk.h

2)

-include file
    Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.

--> so not the same behavior as a regular include --> makes things just more complicated and less consistent

3) an include should be issued in the source file who actually needs it, not by some external force, otherwise one more extra 'invisible' source for breaking the builds

4) darn pch : they are the cause of 99% of our builds being broken [in the sense of doesn't build], and this is once more related in this use case with pch (sdk.h)

5) now every file is forced to work with the pch, no choice if you have a simple file that nearly needs anything from the sdk.h [then at least you had the freedom to work without the pch in that file]


I haven't removed that option yet from the cbp's, but I really like to ;-)

[thomas]

4) darn pch : they are the cause of 99% of our builds being broken [in the sense of doesn't build], and this is once more related in this use case with pch (sdk.h)

They're the cause of making the build 12-15 times faster too, however. And honestly, I don't think it is really the fault of precompiled headers, rather we're probably just not using them right. sdk.h, sdk-common.h, sdk-precomp.h #ifdef BLAH ... nobody understands what to use at what time, and what's valid at which time anyway
For example, if I understand your above code snippet right, then in non-PCH mode, all sources will include everything once, and then include a subset manually again, which isn't precisely the most efficient.

5) now every file is forced to work with the pch, no choice if you have a simple file that nearly needs anything from the sdk.h

Which should be perfectly alright, though. Using the whole precompiled SDK header is much more efficient than including 1-2 "small" headers such as wxString that are not precompiled.

What I think would be the right thing is this:

• Rename CB_PRECOMP to something more understandable. Really, what does CB_PRECOMP mean? Does it say "use precompiled headers" or does it say "precompiled headers have already been parsed"? I bet half of the time, someone assumes the wrong thing. Something like USE_PRECOMP is less confusing, in my opinion.
• Have one file that includes pretty much everything. This file should be named in a way that makes clear nobody is to use it directly, such as sdk-internal.h. It might have an #error clause too, if some particular magic constant is not defined (when included directly).
• Have two properly named files which are for use with the SDK and with the application and plugins. I'm not sure about what the precisely best names would be, but it should be clear from the names that one is for the SDK and one is for the application and plugins.
  One of these defines BUILDING_SDK and the other does not, that way we have DLLIMPORT and DLLEXPORT defined correctly, according to what the headers are used for. Then they define the secret constant to prevent the #error, and include sdk-internal.h. No additional magic, no ifs and whens. These two files are the ones that get precompiled in the build process.
• Have every file do this:

#if USE_PRECOMP
#include "whatever-the-magical-precomp-name.h"
#else
.... 20 individual includes here
#endif

That should work correctly, and it should work with acceptable performance for the few people who don't use precompiled headers, too. It would be easy enough so nobody can do anything wrong, too. Plus, if someone is writing a plugin and is too lazy to figure out what he needs (that's me!), he can just skip the #ifdef, and it will still work. If someone is afraid of precompiled headers, he can too just skip that line and include whatever he wants, it'll work.

[killerbot]

For those who have access to the scratchpad (CB developers) have a look at my entry in there.

I will quote some part of it here below.

They're the cause of making the build 12-15 times faster too, however.

I know, but not really in CB, it slows down the build. Mainly because our sdk was not that stable, mostly because our sdk does not exist out of interfaces, but contains state (even in the worst possible form (public and protected members). But yes, I agree, it can provide speed-up (explained more or less in my quote below).

Which should be perfectly alright, though. Using the whole precompiled SDK header is much more efficient than including 1-2 "small" headers such as wxString that are not precompiled.

Dangerous and maybe the few includes that were really needed in a file might have a faster compilation. There's a threshold, but what it the amount of headers to include to use either approach ?

CB_PRECOMP is kind of mimicked from WX_PRECOMP. But as will be explained below it does not guarantee that it will be pch. CB on it's projects will try to use pch, but it can be overruled for whatever reason (maybe because the compiler doesn't support it). And both work as it is now.
Well nearly work, the only thing needed is that the developers check that #include "sdk.h" brings nearly the entire world, is not good enough for the entire world, in case of no pch, it brings nothing (or the other option would be it brings way too much).

So finally here is my own quote, which explains the current schema for header inclusion (pch/non-pch).

4. pch's
Consider that several implementation files (so does not apply for headers), include all the time a nearly identical set of headers (for example we have 10 source files, and all of them include header files A, B and C) then the include statement of those 3 headers can be put in a separate header and the 10 sources include that special header. It is obvious this is in conflict with the third rule of good inclusions. And suppose we have 5 files which all of them include headers A and B, maybe those can also include that special header then, although they get one header to many in the end, so we are in conflict with the second rule. On the other hand (if there are no special ifdefs in the header, so not the guards) several compilers can "pre"-compile this special header and immediately copy in the result of this compilation in the eventual compilation of the sources, it is obvious by doing this once, instead for all those sources, a speed-up in the compilation process is achieved. So that's the (big) benefit of pch's. But it very easy to see the golden rules get violated and this might lead to code of lesser quality. And how about when you are reading the code on paper, hmmm nice we include a special header, well let's hope it includes everything we need.
Not all compilers support pch's, so if you write code (like the sources from CodeBlocks, wxWidgets) that should compile with different compilers, or different version of compilers, then you need to do it both ways. Then we can serve both parties, the fans of the pch's and we are obliged to do it also the "clean" way since otherwise it will not compile. That is, in the case of no pch support those special headers turn up to be no-ops. And they should, otherwise it is very hard for maintenance (what if a certain header get's kicked out of the pch -> woops : compile errors) and otherwise all those nice rules are violated just for nothing (because there's no speed-up, only things get slower, because several sources will be including stuff they didn't need). Most of the time the files included in a pch are headers that don't change that much like, headers from an sdk/api : CodeBlocks sdk, wx api, windows api. Note that because of such a bottleneck, if one of the headers in the pch change all files dependent on the pch need to recompile (even thoug in the end it might have been because of a header in the list they didn't need). So use pch's wisely and make sure you always program at the same time according to the golden rules.
This brings us to a first template on how to do inclusions for the CodeBlocks sources.

Code

#ifdef PCH_MODE
#include our pch
#else
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list

It is obvious that this requires maintenance over time depending on what is added/removed from pch. Headers can move to/from the #else part to/from the part outside the #ifdef#else#endif construct. As we code, we should always check the list of headers in the pch.

CodeBlocks sources use 2 pch's : the CodeBlocks sdk and the wx sdk, where the CodeBlocks sdk pch will take care of the wx sdk pch.
The fact that pch's are used is defined on the project level, the projects of the CodeBlock sources specify they will use pch's. However since certain compilers don't support pch's, the specification on the project level needs to be overruled and turned off. One could also remove the setting from the project files by hand when using those non-pch compilers, but it is a common practice to have it turned off by means of a header file that checks which compiler is being used and if needed turn off the setting (normally a preprocessor define is used for this purpose). The object oriented approach would be to have a dedicated file doing the check and overrule and then our template would look something like this :

Code

#include use_pch_check    // so this one could undef the PCH_MODE
#ifdef PCH_MODE
#include our pch
#else
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list

Although less object oriented (1 responsibility in 1 place and the other way around), but often used is that the pch itself does the check. From the things discussed above, good practice (our golden rules) requires the pch to look something like this :

a_pch_template.h

Code

// check on the compiler (or other settings) if we need to #undef PCH_MODE
// if it is not undef-ed we include our list of headers
#ifdef PCH_MODE
 // here comes our list with headers we include in the pch
#endif // PCH_MODE

Then our template needs to look like this :

Code

#include our pch
#ifndef PCH_MODE
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list

When Code::Blocks is using precompiled headers it will automatically also turn on the usage of precompiled headers on wxWidgets. The preprocessor defines activating the precompiled headers are :
  - CB_PRECOMP (for Code::Blocks sdk headers)
  - WX_PRECOMP (for wxWidgets headers)
the pch checking/overruling headers are :
  - sdk.h (Code::Blocks)
  - wxprec.h (wxWidgets)
Since Code::Blocks drives also the pch mode of wxWidgets we can just focus on the CB_PRECOMP/sdk.h .

As a result our header/include template becomes :

Code

#include "sdk.h"
#ifndef CB_PRECOMP
#include headers from the sdk.h we actually need
#endif
#include all other headers we need who are not in sdk.h

Although wxprec.h already has a list of headers included in the precompilation, Code::Blocks has created an extra list of wx headers to use in the precompilation list. This extra list together with the Code::Blocks headers can be found in sdk_precomp.h (this one is included from the sdk.h). Note as far as the wx headers are concerned there's some overlap in the official wx list and the Code::Blocks-wx list.

[killerbot]

by the way, after discussing with the 'Don' we would remove that "-include sdk.h" option in the cbp file. So CB will build with TDM-GCC gcc 4.3.2 out of the box then. :-)

[stahta01]

by the way, after discussing with the 'Don' we would remove that "-include sdk.h" option in the cbp file. So CB will build with TDM-GCC gcc 4.3.2 out of the box then. :-)

I updated my patch to remove "-include sdk.h" from all the windows cbp.
I also, submitted another patch needed to get wxSmith working again after removing "-include sdk.h"
Tim S
See patches
http://developer.berlios.de/patch/?func=detailpatch&patch_id=2560&group_id=5358
http://developer.berlios.de/patch/?func=detailpatch&patch_id=2559&group_id=5358

[TDragon]

GCC 4.3.2 TDM-2 (the second 4.3.2-based TDM release) is now available. Binary packages are provided as drop-in replacements for the MinGW project's official gcc packages.

I've ensured that this release can build and run wxWidgets (2.8.9) and Code::Blocks (SVN 5331; no modifications!). If you were using 4.3.2-tdm-1 with Code::Blocks and couldn't get breakpoints in headers, this should now be fixed. Please note that the TDM 4.3 releases continue to use MinGW/3.4.5's exceptions/DLLs hack for now. (Hack that it is, this method nevertheless works supremely well.)

Full details and download links are at http://www.tdragon.net/recentgcc/ .

Disclaimer:
The TDM-GCC builds are unofficial replacements for the official MinGW releases of GCC binaries. TDM-GCC was previously recommended for experimentation purposes only, but constant use in day-to-day development and a total download count of over 30,000 have proven the TDM-GCC releases to be at least as usable as the most recent official MinGW GCC release. (Please note that this does not mean that there are no bugs; merely that there is a different set of bugs with a similar or lesser average criticality.) Therefore, TDM-GCC is now heartily endorsed for production use in any non-critical environment, with only the following caveats:

• TDM-GCC is not formally affiliated with or endorsed by the MinGW project (although several MinGW team members make use of it)
• No level of support for TDM-GCC is in any way guaranteed (although a best effort is made to fix bugs as they are found or forward them to GCC Bugzilla)

Cheers,
John E. / TDM

[olelukoie]

GCC 4.3.2 TDM-2 (the second 4.3.2-based TDM release) is now available. Binary packages are provided as drop-in replacements for the MinGW project's official gcc packages.
...
Cheers,
John E. / TDM

I've got a question. In your description of bundled installer I see that you use mingw-runtime 3.14. Why you don't use latest (3.15.1) version? Is there some critical bugs or incompatibilities? Or it is just incorrect description and indeed you packaged 3.15.1?

[stahta01]

I've got a question. In your description of bundled installer I see that you use mingw-runtime 3.14. Why you don't use latest (3.15.1) version? Is there some critical bugs or incompatibilities? Or it is just incorrect description and indeed you packaged 3.15.1?

The auto downloader gave me mingw-runtime 3.14; so, I would say it the same for bundled installer.
TDM waits a little while before upping the mingw-runtime version. When 3.16 happens he will likely have moved to 3.15.x.

Tim S

[TDragon]

Actually, the reason is that there are a couple of relatively critical bugs in mingwrt 3.15.1 (which have since been fixed in CVS, and 3.15.2 is expected soon). I had bumped the installer to mingwrt 3.15.1 for the 1.808.3-f2 release (and auto-download), but reverted it to 3.14 until these bugs are fixed.