Author Topic: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)  (Read 60458 times)

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« on: May 31, 2008, 05:19:38 am »
(Updated for the release of GCC 4.3.3 TDM-1)

GCC 4.3.3 TDM-1 is now available. Binary packages are provided as drop-in replacements for the MinGW project's official gcc packages.

This release successfully builds wxWidgets 2.8.9 and Code::Blocks SVN r5473. There are some interesting vtable import diagnostics produced, which I'll be looking into, but they don't affect the final binary's usability.

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 50,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)


----- Older updates follow -----

(Updated for the release of GCC 4.3.2 TDM-2)

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.)

(Updated for the release of GCC 4.3.2 TDM-1)

A TDM experimental build of GCC 4.3.2 for MinGW 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.8) and Code::Blocks (SVN 5196). As with previous 4.3 builds, minor modifications were necessary in the C::B sources. Also, the TDM 4.3 releases continue to use MinGW/3.4.5's exceptions/DLLs hack rather than a shared libgcc, for now.

(Updated for the release of the TDM/MinGW Installer)

An installer program for TDM-GCC and MinGW has been released. The installer creates, manages, and removes MinGW installations, and can upgrade components when new versions are available.

(Updated for the 4.3.1-tdm-1 release)

A TDM-1 build of GCC 4.3.1 for MinGW 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.7) and Code::Blocks (8.02). As with previous 4.3 builds, minor modifications were necessary in the C::B sources. Also, the TDM 4.3 releases continue to use MinGW/3.4.5's exceptions/DLLs hack rather than a shared libgcc, for now.

(Updated for the 4.2.4-tdm-1 release)

I've created binary releases of GCC 4.3.0 and 4.2.4 for MinGW. Binary packages are available as drop-in replacements for the MinGW project's official gcc packages.

I finally got around to taking a look at why the C::B build was failing for 4.3.0. Some of the errors were caused by a bug which I posted in GCC bugzilla and which was promptly fixed. Two further errors were undefined references to the vtables of fully defined classes declared as dllimport; this I fixed by removing the dllimport. The remaining error came from an as-yet-unidentified PCH bug, and I worked around it by removing the -include "sdk.h" from one of the targets.

Therefore, the 4.3.0 release has finally built and run wxWidgets 2.8.7 and Code::Blocks SVN 5081.
The 4.2.4 release incorporates the same local patchset as previous releases in the 4.2 series, and as usual builds and runs wxWidgets and Code::Blocks without any problems.

Of note: I've ported the official MinGW/GCC 3.4.5 exceptions/DLLs hack forward and used it in this 4.3.0 release because of currently unsolved errors in the shared libgcc and libstdc++ of the previous release (and because I personally prefer this method to DLL hell).

Cheers,
John E. / TDM
« Last Edit: February 28, 2009, 01:31:05 am by TDragon »
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.0 for MinGW
« Reply #1 on: June 01, 2008, 04:37:38 am »
Did you try compiling the Contrib Help project?

I got some errors about the std::find not existing.

Edit: I think it might be a side effect of my deleting of the pre-compiled headers.
Edit2: adding #include <algorithm> fixed this issue.

Tim S

« Last Edit: June 01, 2008, 05:11:15 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline zelsazgh

  • Single posting newcomer
  • *
  • Posts: 3
Re: TDM-GCC 4.3.0 for MinGW
« Reply #2 on: June 01, 2008, 01:41:34 pm »
Wow!!! some one can compiler ada in mingw!!! how do you compile it? can u tell me?

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.0 for MinGW
« Reply #3 on: June 01, 2008, 04:05:58 pm »
In this case, I was already building the rest of the languages as a native bootstrap; I added Ada to the list of languages to build and it just seemed to work. To see my build scripts, download gcc-4.3.0-tdm-3-srcbase.zip from the TDM-GCC project's SourceForge download page.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.0, 4.2.4 for MinGW
« Reply #4 on: June 10, 2008, 02:12:11 am »
A TDM-1 binary release of GCC 4.2.4 is now available for MinGW. Binary packages are available as drop-in replacements for the MinGW project's official gcc packages.

The 4.2.4 release incorporates the same local patchset as previous releases in the 4.2 series, and as usual builds and runs wxWidgets and Code::Blocks without any problems.

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

Disclaimer:
The TDM-GCC builds are unofficially created packages designed to replace, for experimentation purposes, the official MinGW releases of GCC binaries. The TDM-GCC builds typically contain fewer changes from the vanilla sources and receive less testing than their official counterparts. Since these builds are not formally affiliated with or endorsed by the MinGW project, they should be treated as unstable and unsupported software -- in other words, use it at your own risk.

Cheers,
John E. / TDM
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW
« Reply #5 on: June 26, 2008, 08:46:48 pm »
A TDM-1 build of GCC 4.3.1 for MinGW 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.7) and Code::Blocks (8.02). As with previous 4.3 builds, minor modifications were necessary in the C::B sources. Also, the TDM 4.3 releases continue to use MinGW/3.4.5's exceptions/DLLs hack rather than a shared libgcc, for now.

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

Disclaimer:
The TDM-GCC builds are unofficially created packages designed to replace, for experimentation purposes, the official MinGW releases of GCC binaries. The TDM-GCC builds typically contain fewer changes from the vanilla sources and receive less testing than their official counterparts. Since these builds are not formally affiliated with or endorsed by the MinGW project, they should be treated as unstable and unsupported software -- in other words, use it at your own risk.

Cheers,
John E. / TDM
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW
« Reply #6 on: June 29, 2008, 07:34:39 am »
Do I need to explicitly add libraries for 4.3.1 I don't need for 4.2.0? I get linking errors for wstring (lots of undefined references to std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >).

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW
« Reply #7 on: June 29, 2008, 01:57:38 pm »
Do I need to explicitly add libraries for 4.3.1 I don't need for 4.2.0? I get linking errors for wstring (lots of undefined references to std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >).

I have no idea, but for 4.30 I was having issues relating to using precompiled headers.
So, it might be the same issue.

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW
« Reply #8 on: June 29, 2008, 02:34:32 pm »
Nah, my bad, sorry. I forgot to update the library search path so it tried to link against the wrong libstd++.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW (now with installer)
« Reply #9 on: August 02, 2008, 09:55:30 pm »
An installer program for TDM-GCC and MinGW has been released. The installer creates, manages, and removes MinGW installations, and can upgrade components when new versions are available.

TDM-GCC is a set of drop-in replacements for the MinGW project's GCC packages.

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

Disclaimer:
The TDM-GCC builds are unofficially created packages designed to replace, for experimentation purposes, the official MinGW releases of GCC binaries. The TDM-GCC builds typically contain fewer changes from the vanilla sources and receive less testing than their official counterparts. Since these builds are not formally affiliated with or endorsed by the MinGW project, they should be treated as unstable and unsupported software -- in other words, use it at your own risk.

Cheers,
John E. / TDM
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW (now with installer)
« Reply #10 on: August 02, 2008, 10:35:29 pm »
Any chance for Dwarf2? Yes, I'm picky as usual, but Dwarf2 just rocks.  :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW (now with installer)
« Reply #11 on: August 03, 2008, 05:19:07 am »
Not bundled, but you can choose it in either installer to be downloaded on-demand; and, of course, you can always download it from the SF page and unpack it yourself.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW (now with installer)
« Reply #12 on: August 03, 2008, 01:44:13 pm »
Huh? I must be blind then, didn't find any DW2 zips on SF... have to look again. :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.3.1, 4.2.4 for MinGW (now with installer)
« Reply #13 on: August 03, 2008, 01:45:56 pm »
Ow man... please donate, I need glasses...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (now with installer)
« Reply #14 on: August 30, 2008, 05:36:02 am »
A TDM experimental build of GCC 4.3.2 for MinGW 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.8) and Code::Blocks (SVN 5196). As with previous 4.3 builds, minor modifications were necessary in the C::B sources. Also, the TDM 4.3 releases continue to use MinGW/3.4.5's exceptions/DLLs hack rather than a shared libgcc, for now.

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

Disclaimer:
The TDM-GCC builds are unofficially created packages designed to replace, for experimentation purposes, the official MinGW releases of GCC binaries. The TDM-GCC builds typically contain fewer changes from the vanilla sources and receive less testing than their official counterparts. Since these builds are not formally affiliated with or endorsed by the MinGW project, they should be treated as unstable and unsupported software -- in other words, use it at your own risk.

Cheers,
John E. / TDM
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (now with installer)
« Reply #15 on: September 02, 2008, 05:01:55 pm »
As with previous 4.3 builds, minor modifications were necessary in the C::B sources.

Are they significant modifications?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (now with installer)
« Reply #16 on: September 02, 2008, 06:17:58 pm »
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&);
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #17 on: September 02, 2008, 08:36:39 pm »
any reason why we would not apply this already today ?

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (now with installer)
« Reply #18 on: September 02, 2008, 08:46:43 pm »
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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #19 on: September 02, 2008, 09:14:20 pm »
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.  :)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #20 on: September 08, 2008, 01:39:44 am »
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&);
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #21 on: September 08, 2008, 09:37:46 am »
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)
Quote
-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 ;-)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #22 on: September 08, 2008, 12:19:45 pm »
Quote
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.

Quote
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #23 on: September 08, 2008, 01:21:58 pm »
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.

Quote
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).

Quote
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.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #24 on: September 08, 2008, 01:28:19 pm »
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. :-)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #25 on: September 09, 2008, 11:50:36 pm »
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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #26 on: December 10, 2008, 05:53:17 am »
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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline olelukoie

  • Single posting newcomer
  • *
  • Posts: 7
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #27 on: December 14, 2008, 10:37:25 am »
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?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #28 on: December 14, 2008, 07:03:01 pm »
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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2, 4.2.4 for MinGW (with installer)
« Reply #29 on: December 15, 2008, 12:03:23 am »
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.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #30 on: December 16, 2008, 02:46:56 pm »
Hi, TDragon .
Thanks for your effort to provide this great tool. And I have download it and install it. It seems that it's faster then the one in 8.02 installer. :D, And I have update some wiki page to describe the package installation. Because the old wiki page haven't tell this method. They just tell us to download many packages separately and unzip to one folder.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #31 on: December 17, 2008, 01:21:19 am »
That's fine, ollydbg, but do remember that (in contrast with the official MinGW GCC distribution) no support is guaranteed in using TDM-GCC -- there is no mailing list or forum, and tracker items that aren't actual bugs are usually deleted. This makes the official MinGW version much more desirable from the standpoint of the Code::Blocks devs, because they have a place they can redirect requests for help to.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #32 on: December 28, 2008, 09:27:20 am »
Quote
hi, TDragon.
I find that in the wiki page:
http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks

The GDB doesn't support set breakpoints in a constructor. I tested in your package,  It's true :(.
I'm not sure if this limitation is removed yet? Thanks.

Above was my original message. I'm sorry I make a mistake. You package contains the GDB 6.8.3, from GDB 6.8 it is support breakpoints in constructor. Your package works well. I have mixed the one in 8.02 setup.  :(.

Sorry.

« Last Edit: December 28, 2008, 04:55:34 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #33 on: December 28, 2008, 10:49:40 am »
Quote
Hi, I have found that the mingw GDB 6.8.3 version is support setting breaking point in the class constructors.
So, I have download these files from:

http://www.esnips.com/doc/a9e03a9e-7a36-4357-9093-09d0188825f9/gdb-6.8-3-MinGW

and I copy the gdb.exe and gdbserver.exe to my Mingw/bin folder. When a message box prompt that a file named " iconv.dll" is need to run gdb.exe.

So, I searched on Google, and find one from
ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip

Now, the GDB can step into the constructor of a class. :D.
I have made a mistake, see the above message. :D
« Last Edit: December 28, 2008, 04:57:46 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #34 on: January 16, 2009, 03:09:48 am »
I just want to express my great thanks to TDragon.
He help me to fix the problem in building opencv libraries. I have reported to the opencv to fix this bug.
Thank you very much.

A discussion can be found here:
https://sourceforge.net/tracker2/?func=detail&aid=2505869&group_id=200665&atid=974439
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #35 on: January 16, 2009, 05:31:04 am »
You're welcome. :)

By the way, I'll be abroad in the Philippines with limited internet access for the next 4 weeks, so try not to find any more bugs during that time. ;)

-John E. / TDM
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #36 on: February 23, 2009, 02:20:34 pm »
@TDragon

You should update the OP in this thread. :D, because TDM 4.3.3 is released. Thanks. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #37 on: February 24, 2009, 01:21:14 am »
You should update the OP in this thread. :D, because TDM 4.3.3 is released.

I haven't yet built wxWidgets or Code::Blocks with it.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.2 (TDM-2) for MinGW (with installer)
« Reply #38 on: February 24, 2009, 01:30:49 am »
You should update the OP in this thread. :D, because TDM 4.3.3 is released.

I haven't yet built wxWidgets or Code::Blocks with it.

I have successfully built code::blocks in tdm-4.3.3. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #39 on: February 28, 2009, 01:30:30 am »
GCC 4.3.3 TDM-1 is now available. Binary packages are provided as drop-in replacements for the MinGW project's official gcc packages.

This release successfully builds wxWidgets 2.8.9 and Code::Blocks SVN r5473. There are some interesting vtable import diagnostics produced, which I'll be looking into, but they don't affect the final binary's usability.

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 50,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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #40 on: February 28, 2009, 12:24:36 pm »
You're the best, thank you, John  8)

By the way,  the hex editor reveals strings in all executables built with the TDM suite which look suspiciously like asserts to me, such as "ret->size == sizeof(__cygming_shared) && "GCClib shared data size mismatch". I don't know if those are present in exes built with the official MinGW too (not been using them for a year).
They don't go away if I define NDEBUG though. On the other hand, why should they... if the compiler is built in debug mode, then the compiler should contain these asserts, but wouldn't place them in the executable, would it... :)

Any idea what that is and how to get rid of? It's not like it really hurts anything, but it puzzles me.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #41 on: February 28, 2009, 06:45:05 pm »
By the way,  the hex editor reveals strings in all executables built with the TDM suite which look suspiciously like asserts to me, such as "ret->size == sizeof(__cygming_shared) && "GCClib shared data size mismatch". I don't know if those are present in exes built with the official MinGW too (not been using them for a year).
They don't go away if I define NDEBUG though. On the other hand, why should they... if the compiler is built in debug mode, then the compiler should contain these asserts, but wouldn't place them in the executable, would it... :)

Any idea what that is and how to get rid of? It's not like it really hurts anything, but it puzzles me.
Yes, they are asserts. They are part of the exceptions-from-DLLs mechanism in libgcc, and are basically the only choice for ending your program in a quasi-helpful manner if the mechanism fails. They are in the official MinGW as well: "w32_sharedptr->size == sizeof(W32_EH_SHARED)".

No way to get rid of it except by rebuilding your own GCC, sorry.

-John E. / TDM
« Last Edit: February 28, 2009, 06:46:40 pm by TDragon »
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #42 on: March 29, 2009, 09:57:59 am »
@TDragon
I have successfully build the OpenCV libraries with OpenMP enabled. Great! Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

neub

  • Guest
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #43 on: May 12, 2009, 03:58:56 pm »
Thanks, I have finally built the last openCV with the TDM-MinGW...
However I have a question about the include in C++.

Under linux I have a directory /usr/include/c++/4.3/, however I don't find it in your version of MinGW.
I hope that I could find a C:/MinGW/include/c++/4.4/ path with the c++ includes.

So i was just wondering where was this folder?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #44 on: May 12, 2009, 04:42:27 pm »
Have you looked at lib\gcc\mingw32\4.4.0\include\c++\bits

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

neub

  • Guest
Re: TDM-GCC 4.3.3 (TDM-1) for MinGW (with installer)
« Reply #45 on: May 12, 2009, 04:52:05 pm »
Thanks, I was just looking at this :)
C:\MinGW\lib\gcc\mingw32\4.4.0\include\c++