TDM-GCC 4.7 series (Latest: 4.7.1 - 2012-09-15)

[TDragon]

After much ado fighting with upstream GCC changes, and just barely squeaking in before the upstream 4.7.2 release, I would like to proudly present:

TDM-GCC 4.7.1!
The 4.7 GCC stable release series includes much-improved C++11 support (with new -std=c++11 and -std=gnu++11 options), OpenMP 3.1, a bunch of optimizer improvements, and lots of other new features.

The TDM release of GCC 4.7.1 is now available for download. As always, I've tested it on wxWidgets (2.8.12) and Code::Blocks SVN (8394) to ensure good compatibility. You can build Code::Blocks with either the TDM32 edition ("out of the box"), or the TDM64 edition (using the MinGW-w64 project's runtime and the "-m32" flag for 32-bit compilation). When building wxWidgets as a MONOLITHIC DLL, you will probably need to use the "-fno-keep-inline-dllexport" flag (mingw32-make ... CXXFLAGS="-fno-keep-inline-dllexport").

A couple of minor tweaks:

• The 64-bit version of GDB is now built with Python support.
• The MinGW-w64 runtime package now includes the gendef and genidl tools and the libmangle library.

TDM-GCC comes in TWO editions:
You can choose between the classic MinGW 32-bit edition and the new TDM64 edition. The TDM64 edition is based on the MinGW-w64 runtime API and the x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit code, with the "-m32"/"-m64" compiler flags. Please be aware, if you build Code::Blocks yourself, that it only works as 32-bit code ("-m32") on Windows, currently -- though that will hopefully change soon. Also, please never mix 32-bit object files (.o), libraries (.a), DLLs, or EXEs with 64-bit versions, and don't report it as a bug if you inadvertently do.

More information and downloads are available at <http://tdm-gcc.tdragon.net/>. TDM-GCC includes support for C, C++, Fortran, Objective-C/C++, and Ada (MinGW edition only), as well as support for the OpenMP multithreading extensions, packaged in a simple Windows installer.

Disclaimer:
As always, please remember:

• TDM-GCC is not formally affiliated with or endorsed by the MinGW project.
• 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

[ollydbg]

Nice work, John.

[killerbot]

what a splendid surprise :-)

many many thanks

[Jenna]

Many thanks !

I have a first issue:
mingw32-make.exe can not be started, neither in the 32-bit nor in the 64-bit default installation.
It complains about missing libgcc_s_dw2-1.dll .

[MortenMacFly]

HOORAY! Open the bottles of champagne! ;-)

I have a first issue:
mingw32-make.exe can not be started, neither in the 32-bit nor in the 64-bit default installation.
It complains about missing libgcc_s_dw2-1.dll .

Same here. :-(

Is it OK to copy that DLL from the DWARF2 package, or is the make package corrupted/swapped?

[Jenna]

HOORAY! Open the bottles of champagne! ;-)

I have a first issue:
mingw32-make.exe can not be started, neither in the 32-bit nor in the 64-bit default installation.
It complains about missing libgcc_s_dw2-1.dll .

Same here. :-(

Is it OK to copy that DLL from the DWARF2 package, or is the make package corrupted/swapped?

I just did it and it seems to work.
I'm currently compiling wxWidgets 2.9.4 and will see what happens.

[MortenMacFly]

I'm currently compiling wxWidgets 2.9.4 and will see what happens.

Me, too - lets see who's first...

BTW (slightly OT): Is it safe to use something like -j2 for the wx builds? I never tried, but saw this:
http://trac.wxwidgets.org/ticket/14470
I also wonder, if we could/should use the same concept (the very last post of vadz) proposed there for our make based build concerning PCH files?! (Maybe we do that already... I ma not using make file builds of C::B that often...)

[oBFusCATed]

BTW (slightly OT): Is it safe to use something like -j2 for the wx builds? I never tried, but saw this:

I think, I'm using -j5 on linux, so probably it will work on windows, but last time I've tried it failed. I think. But the build on windows is pretty easy to get failed.

[Jenna]

I'm currently compiling wxWidgets 2.9.4 and will see what happens.

Me, too - lets see who's first...

Most likely you, because I'm building in a VM.

BTW (slightly OT): Is it safe to use something like -j2 for the wx builds? I never tried, but saw this:
http://trac.wxwidgets.org/ticket/14470
I also wonder, if we could/should use the same concept (the very last post of vadz) proposed there for our make based build concerning PCH files?! (Maybe we do that already... I ma not using make file builds of C::B that often...)

I will see if I find an option (or tweak or whatever) for autotools to ensure pch's are build first.

EDIT:

To avoid cluttering this thread, I continue the discussion about pch's with C::B here: http://forums.codeblocks.org/index.php/topic,16867.msg114757.html#msg114757

[TDragon]

Ugh ... that's the official MinGW project's mingw32-make, so that I don't have to build and distribute it myself. It depends on the libintl DLL, which apparently now depends on the libgcc DLL. Welcome to DLL hell.
I'll update the installer in a little while.

The mingw32-make job server doesn't actually work with nested Makefiles, but with flat Makefiles like that of wxWidgets it works great. I've been building wxWidgets with -j8 for years now and it takes about 3 minutes on my quad-core hyperthreading Core i7.

[sophron]

For the dw2 version, the "liblto_plugin-0.dll" should be located in "MinGW32\libexec\gcc\mingw32\4.7.1-dw2" rather than "MinGW32\bin".

[TDragon]

You're absolutely right, I apologize for not checking that edition more carefully.

I've rolled a -2 version of the DW2 core package, and updated the installer to include the libgcc DW2 DLL when installing mingw32-make or gdb. If you want to use the installer's update feature to get the DLL, you will need to *uninstall* one of those packages (mingw32-make or gdb), and then reinstall it, with the "Check for updated files ..." option checked.

[ptDev]

Happy days!

Congratulations for the great breakthrough (4.7 had many changes with a big impact for the Windows port of GCC)! I'll stop annyoing you about "the next release" for a long while, I promise!

Now, to rebuild wx2.8 and Code::Blocks, and to pack a new unofficial installer. I must be lagging behind the official nightly builds big time!

[Alpha]

Thank you!

[gd_on]

Thank you too !
Just a question for my information. I compiled and linked succesfully C::B svn 8395 on my PC (Windows 7) with this new 4.7.1 tdm version (full build), but I kept my "old" version of the wxwidgets dll, compiled with tdm 4.6.1. After installing C::B as usual, this new built version crashed at initialisation. I then re-compiled the wxwidgets monolithic dll with tdm 4.7.1, and, that time, everything was OK.
So, have you an idea, for my curiosity, why C::B and the wxWidgets dll seems to work together only when they are compiled with the same version of compiler ? Strange isn'it ?

gd_on

[ollydbg]

why C::B and the wxWidgets dll seems to work together only when they are compiled with the same version of compiler ?

See this topic http://thread.gmane.org/gmane.comp.gnu.mingw.user/39408
detailed answer http://article.gmane.org/gmane.comp.gnu.mingw.user/39411
Especially the "Binary incompatibility notice!"

[TDragon]

Not at all strange. The C++ ABI is known to change between GCC releases. In general it's best to assume that any minor release increment (e.g. 4.6 to 4.7) will include a C++ ABI change.

[gd_on]

OK. Thanks for your answers.

gd_on

[MortenMacFly]

Mmmmh... on Windows I have that feeling, that compiling with GCC4.7.x is significantly slower than with GCC4.6.x. Could that be? Maybe its just because I need to re-compile everything, but I did that before, too and it seemed way faster...?!

[zabzonk]

Mmmmh... on Windows I have that feeling, that compiling with GCC4.7.x is significantly slower

I just timed them both on a moderate sized project of mine. There is a difference - 4.7.1 seems to be about 15% slower than 4.6.1.

Edit: Oops, my maths! Make that about 10% slower.

[gd_on]

I have tested this while generating wxWidget 2.8.12, both a dll monolithic version and a static library on my PC
With gcc 4.6.1 : 28 minutes
With gcc 4.7.1 : 30 minutes. Just a little bit slower.

More interesting, size of wxmsw28u_gcc_cb.dll in lib\gcc_dll :
With gcc 4.6.1 : 16789 ko before strip and 6803 ko after
With gcc 4.7.1 : 16330 ko before strip and 6371 ko after.

and size of libwxmsw28u.a in lib\gcc_lib :
With gcc 4.6.1 : 17675 ko
With gcc 4.7.1 : 17271 ko

So, differences are weak. gcc 4.7.1 is just a little lit slower, but has produced a little bit smaller libraries.

gd_on

[Alpha]

Maybe 4.7 just enables more optimizations (or has more aggressive versions of previous ones).

(If anyone wants to try) a (probably) level test would be a comparison of compile time and output size, with all optimizations disabled.

[xazax]

Any plans with 4.7.2?

This one bothers me:

A notable change in GCC 4.7.2 compared to 4.7.1 are ABI bug fixes related to some C++11 templates (std::list and std::pair). As a result, code using those templates in C++11 mode is again ABI compatible with code in C++03/C++98 mode or C++11 mode of GCC 4.6 and earlier, but might be ABI incompatible with code compiled by GCC 4.7.1 or 4.7.0 in C++11 mode.

[TDragon]

We'll see. The 4.7 series is already ABI incompatible with 4.6 series and earlier in other areas.

[oBFusCATed]

Does this release support std::thread and all the other classes for synchronization, std::atomic, std::chrono and std::random at the same level as the linux version?
I have a project that is GCC 4.7 only at the moment and I would want to port it to windows.

[TDragon]

Unfortunately, no. The libstdc++ threading support is based on pthreads, while TDM-GCC is currently built with Win32-style threads. There is not a 1-to-1 correspondence between the Linux (pthreads) threading model and the Windows threading model, and ideally someone needs to contribute a Windows version of the libstdc++ threading support.

There has been some noise in the last year or so about Mingw-w64's winpthreads library being able to bridge the gap. However, the library is still classified as experimental and I have seen a few bug reports on MinGW-w64's mailing list that make me leery of it. Furthermore, the additional layer of indirection caused by trying to make Windows look like pthreads will only cause additional problems -- we've seen this already with GCC's OpenMP support.

All that said, I may attempt a pthreads-based build at some point in the future and see what comes of it. But your threading support just isn't there right now.

[oBFusCATed]

All that said, I may attempt a pthreads-based build at some point in the future and see what comes of it. But your threading support just isn't there right now.

Thank you for the clarification.

[alexpux]

Hello!
I have long used the TDM-GCC to work. But since it is not updated often passed on http://sourceforge.net/projects/mingwbuilds/. If anyone is interested, there is a building with threads=win32 and with threads=posix using winpthreads. There are releases from 4.6.2 to 4.7.2. There is support for job server for mingw32-make under windows. Project based on mingw-w64. There is a development page for this project on github - https://github.com/niXman/mingw-builds. We would be grateful if you test these assemblies with CodeBlocks.

[PaulS]

Briefly:  I can't build wxWidgets.  Compiles run & then the link gets an exit code 5.  What am I doing wrong?

In Detail: Running Windows 7 with all the latest updates. 
Uninstalled the old Mingw and wxWidgets 2.8.11 (which has been working finme for ages).
Downloaded and ran  tdm-gcc-4.7.1-2.exe.  No obvious problems.  ld--version says 2.22 and g++ --version says 4.7.1.
Download and ran wxMSW-2.8.12-Setup.exe.  Again, no obvious problems.
From wxWidgets-2.8.12/build/msw ran:
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=0 BUILD=release
The compiles run and then what appears to be the link step starts and runs many minutes ending with a windows popup saying that the program isn't responding and then the message "collect2.exe: error: ld returned 5 exit status"

Things I've tried:
- reinstall wxWidgets & run with the clean option first. No difference
- Reinstall wxWidgets & try a unicode build. No Difference.
- An old post to a WxWidgets forum says to unZip again.  After a failure I ran the setup program again & retried the make.  Compiles skipped as expected and the link step fails just as before.

Must be something dumb I'm doing since no one else is complaining.  Any help is much appreciated.

[gd_on]

Works perfectly for me but with a different command line :
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport"
Main difference with yours is UNICODE=1 and probably more important CXXFLAGS="-fno-keep-inline-dllexport" (look for this on the main Tdragon post.)

gd_on

[PaulS]

Thank you very much gd_on.  I added the cxxflags option and both the compile & link ran.  The debug version is compiling now.  One may hope.

Would you direct me to the "main Tdragon post".  It is underlined in your post but is not a link.  The best clue I have for wxWidgets make parameters is the CB wiki & it only mentions the basic options.  A knowledgeable update would be nice.

[Alpha]

It just the first post in this thread.

[PaulS]

DOH.  Craftily hidden in the 3rd paragraph.

I've been at this problem since noon Friday.  Time to relax for a while.

Thanks again.