Code::Blocks Forums

Greetings!

TDM-GCC 4.6.1 is now available!
The latest GCC stable release series includes some stability fixes for Windows targets, better C++11 support, and lots of other new features.

The TDM release of GCC 4.6.1 is now available for download. As always, I've tested it on wxWidgets (2.8.12) and Code::Blocks SVN (7458) 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). Since GCC incorporates the "-fno-keep-inline-dllexport" flag beginning with the 4.6 series, you will probably need to use this flag when building wxWidgets as a MONOLITHIC dll (mingw32-make ... CXXFLAGS="-fno-keep-inline-dllexport").

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/ (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

as always, cheers for John. Thank you very much :-)

Great work, and thanks - it solved my problem (http://forums.next.codeblocks.org/index.php/topic,15140.0.html). :)

Thanks to man who made mingw recent versions easy to install for me when I use windows :)

I can't find TDM-GCC 4.5.2 in the page:http://tdm-gcc.tdragon.net/ (http://tdm-gcc.tdragon.net/) and in sourceforge I also can't find the TDM-GCC 4.5.2.exe consist of all necessary programs because the nightly builds in this forum are complied by GCC4.5.2.  I run a console project compiled by TDM-gcc4.6.1 the cmd window appears after quite a few seconds but if using gcc4.5.2 the window rapidly appears.

Quote from: zage on September 25, 2011, 04:38:47 PM
I can't find TDM-GCC 4.5.2 in the page:http://tdm-gcc.tdragon.net/ (http://tdm-gcc.tdragon.net/) and in sourceforge I also can't find the TDM-GCC 4.5.2.exe consist of all necessary programs because the nightly builds in this forum are complied by GCC4.5.2.  I run a console project compiled by TDM-gcc4.6.1 the cmd window appears after quite a few seconds but if using gcc4.5.2 the window rapidly appears.

In the sourceforge website, you will find TDM-GCC in "TDM-GCC 4.5 series".  I just tried to find it. (but didn't try the installer, because I'm not using windows at home)

http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/tdm-gcc-4.5.2.exe/download

Many thanks!

Unluckily, this build rejects pretty much every piece of code I've ever written with multiple definition of
`typeinfo for A' (A being specialized template classes or classes with virtual functions defined inline in the base) while LTO is active. Which is a real shame seeing how LTO is the one big thing.

This seems to be your problem: http://sourceware.org/bugzilla/show_bug.cgi?id=12762

In the bug they mention a workaround, you could try it...

The big thing about gcc 4.6 is it c++-0x support, not lto, lto will be ready/usable at gcc 4.7 or 4.8 :)

Quote from: oBFusCATed on September 26, 2011, 04:17:50 PM
This seems to be your problem: http://sourceware.org/bugzilla/show_bug.cgi?id=12762

In the bug they mention a workaround, you could try it...

That's exactly the same, yes. The workaround seems to do, though funnily now I have to rename main to __main (since the linker complains otherwise) and manually link against the CRT... on the positive side, executables are considerably smaller than they used to be, just by flipping the magic switch.

QuoteThe big thing about gcc 4.6 is it c++-0x support, not lto, lto will be ready/usable at gcc 4.7 or 4.8 :)

Yeah well, that would be just constexpr, really. It's the only truly interesting thing in 4.6 (from my perspective) that 4.5 did not already support.

Sorry for the off topic question, but, what is LTO?

Link time optimization.

http://gcc.gnu.org/wiki/LinkTimeOptimization

I find also very interesting in 4.6 :
- nullptr
- range based for

:-)

When I compile with -fopenmp, I receive the following:

g++: error: libgomp.spec: No such file or directory

It worked with TDM/GCC 4.4, but not 4.5 or 4.6. Is there any way I can fix this?

Question concerning windows environment :
I installed a complete set of tools, compilers, ... (TDM 32 bits package and some other tools) in C:\MinGW32 and TDM 64 bits package only in C:\MinGW64, on a Win 7 64 bits PC.
To produce software running on this machine, I want to use the 64 bits package.
To produce software running on other machines, XP 32 bits for example, I need to use the 32 bits package.

So, in a cbp projet, I set 2 compiling environments, one I call Release (for standard 32 bits) and one I call Release_64.
Release uses compilers in MinGW32 (gfortran in my test case) and Release_64 uses compilers in MinGW64.
To be able to execute my exe files I had to add C:\MinGW64\bin in my path variable.
And, everything is OK.

My question, is in fact, what would you suggest for the best setting for this path :
I have set in path : C:\MinGW32\bin;C:\MinGW64\bin;... in that order, to give priority to 32 bits tools (because I produce more 32 bits softs than 64 bits).
That's OK within C::B which has is own environment settings, but for tools who have the same name in 32 bits and 64 bits and not configured in toolchains settings (for example strip.exe, and may be some others ...), which version is really used ? Because, with my path setting, I suppose it's the 32 bits version which is first found. And, to your knowledge/experience is it important when building 64 bits applications ?

gd_on

gd_on: Reread the announcement about the 64bit compiler. Read carefully the part where the compiler can produce both 32 and 64 bit binaries.

I suppose you mean the page "Getting started" on TDM site.
I know that the 64 bit version can produce 32 bits soft by adding option -m32. But I would prefer to avoid this solution, because I'd like not to change all my previous settings for 32 bits soft. It's why I installed, in C:\MinGW32 the 32 bits version. Like that, my "old" projects .cbp continue to work as before. So I need, both versions. And as told on that page, I installed them in two different folders.
My question, I think, is more related to the path environment variable, and this page, does not give an answer. If you install automatically both versions, as suggested in 2 different folders (MinGW32 and MinGW64), and accept the modification of the path by the installer, depending on the order of the installation (64 then 32 bit, or 32 bits then 64), you will not have the same order in the path setting. So, I think this might lead to some future problem, it's why I ask if the order of both MinGWxx in path is important or not.

gd_on

I found a solution which works seamlessly now (well, almost... it builds all of my stuff without problems, but still chokes on a thousand undefined wxWidgets symbols when building Code::Blocks, but that is probably my fault, I didn't bother to rebuild wxWidgets yet).

The reason why CRT (and the c++ stdlib) needed to be linked manually was because I put ld as linker into the toolchain settings rather than g++. Now thinking about it, that was not surprising at all.
Setting ld as the linker was necessary in the first place because g++ does not recognize the --allow-multiple-definition commandline option, so the proposed workaround on the bugzilla thread would not work.

Now, luckily, g++ does recognize the -Xlinker option, so you can make it work "the normal way". For whoever is interested in it, this is what I'm using at the moment:

Compiler options: -flto
Linker options: -flto=4 -Xlinker --allow-multiple-definition

byuu -- RE: -fopenmp -- Don't know what to tell you, it works for me. Is there another GCC version getting mixed up with TDM-GCC somehow?

gd_on -- RE: mixing toolchains -- My recommendation in this scenario would be *NOT* to have *ANY* toolchain in the default PATH, then use either the installer-provided .bat file (mingwvars.bat) to create a build & execution environment, or roll your own. I typically just start out with a "clean" command shell, and do "set PATH=C:\toolchain\of\the\moment\bin;%PATH%".

thomas -- RE: -flto -- Glad you got it working. There will always be problems when you don't use a GCC driver to link, unless you are extremely knowledgeable about what flags are being passed around behind the scenes.

Attempts to compile anything using the new version produces a multitude of errors, the first being:

in: include/unknwn.h - error: unknown type name 'interface'
... etc
in: include/unknwn.h - error: unknown type name 'IUnknown'
in: include/unknwn.h - error: unknown type name 'IClassFactory'

Edit: Traced the problem to objbase.h, line 19-23 and 43-4x

#ifndef __OBJC__
#ifndef interface
#define interface struct
#endif
#endif

The problem is that I use ObjC, which means interface never gets defined as a struct, which all the other windows headers require. I haven't had any problems in the past regarding the inclusion of windows headers, so this is a new one to me.

This is a horrible hack but it works and should at least get Objective-C working until a proper fix is found.

At the beginning of windows.h, add:


// ObjC compatibility hack
#ifdef __OBJC__
#define __OBJC_WAS_DEF__ __OBJC__
#undef __OBJC__
#endif


At the end of windows.h, add:


// ObjC compatibility hack
#ifdef __OBJC_WAS_DEF__
#define __OBJC__ __OBJC_WAS_DEF__
#undef __OBJC_WAS_DEF__
#undef interface
#endif


This code only works because I've never had to use the interface definition outside of windows.h, but if you're using Objective-C++, that may be a possibility.

John, is there btw. a way you could not have the DW2 executables tagged -dw2?

I understand that this is meant so one can have several flavours of gcc in the same directory, but it does more evil than good. Having different flavours inside their own top-level directory works nicely to the same effect (and better, in my opinion).

Most build tools (this includes not only tools like automake and cmake, but also e.g. the windres supplied in the TDM install, which calls cpp and gcc) are too fucking stupid to figure out the compiler's proper name if it's anything except gcc. Some are less stupid than others, and some can be told to look for something else, but windres is even too stupid for that.

Which means that you can't build anything that uses windres, including wxWidgets, with the DW2 builds unless you manually make a copy of all files named -dw2.exe without the -dw2 tag first. Shortcuts don't work, for that matter.
This is the source of the totally clueless "windres: gcc exited with status 1" build failure that people encounter every now and then (and to which the error message is not truly helpful if you don't already know what the cause is).

Copying and renaming all the executables is an ordeal though, plus it takes up twice as much disk space than necessary.

Quote from: thomas on September 28, 2011, 02:53:10 PM
John, is there btw. a way you could not have the DW2 executables tagged -dw2?

I agree with thomas. I would also suggest there is a dw2 bundled package installer. :D

Now that I can actually build my applications again using my (hopefully temporary hack), I want to send my thanks out to John. I've been eagerly awaiting GCC 4.6 ever since it was announced that the Objective-C runtime library was being completely rewritten from scratch to support Objective-C 2.0 and bring it inline with Apple's ObjC runtime. I hadn't made the switch though because I wanted to wait for the TDM-GCC 4.6 series; TDM-GCC is so much better and feature packed than other builds of gcc, that other builds aren't even a viable option anymore. 32/64 bit builds, full OpenMP support, ObjC support by standard (instead of as a separate package), etc.

Again, a hearty thanks for helping make Windows platform support comparable to MacOS X support.

Bummer, LTO really isn't quite production just yet.  :lol:

After patching lto-1.exe with a hex editor to be LARGEADDRESSAWARE, I just about managed to build wxWidgets (multimedia and RTTI disabled) with LTO enabled before running out of address space. Kids, don't try this at home if your machine only has 4GB of physical memory. Linking (just linking, not the entire build!) took only about 45 minutes, too.  8)

Unluckily it still gives me missing symbols from wxWidgets when building Code::Blocks (and, funnily, only 2 of them when building c::b without LTO, but around 25 with LTO enabled for c::b). Seems something is just not right yet. Ah well, maybe with gcc 4.7...

Most of the lto problems seems to come from a binutils bug which is being worked on and will be fixed in 2.22.
I use the cvs version and while its not completely bug free it atleast works on most parts.
Also there are some patches for current binutils to fix the multiple-definition problem.

http://sourceware.org/bugzilla/attachment.cgi?id=5870

I havent tried the above patch yet as im deep in Msys2 development.

Hello, im trying to compile wxWidgets 2.8.12 with TDM-GCC 4.6.1 but it fails at the linking process, the console windows show the message "memory exhausted", i use a amd turion x2 processor(1.9 ghz) and 2gb ram, windows xp, also the process takes too much time, approx 1 hour. Before i have tried to compile wxWidgets with the gcc that comes with qt sdk and it finishes without problems and in about 20 min, but it fail to compile codeblocks(for that reason i was trying with TDM-GCC 4.6.1). what can be the reason?

I had a similar problem, but for me the solution is in Tdragon's original post :

QuoteSince GCC incorporates the "-fno-keep-inline-dllexport" flag beginning with the 4.6 series, you will probably need to use this flag when building wxWidgets as a MONOLITHIC dll (mingw32-make ... CXXFLAGS="-fno-keep-inline-dllexport").

It is necessary for me. Have you tried that ?

gd_on

Quote from: thomas on September 26, 2011, 03:56:58 PM
Unluckily, this build rejects pretty much every piece of code I've ever written with multiple definition of
`typeinfo for A' (A being specialized template classes or classes with virtual functions defined inline in the base) while LTO is active. Which is a real shame seeing how LTO is the one big thing.

You can use latest binutils snapshot.
The issue is fixed by Kai.

Quote from: thomas on September 29, 2011, 10:13:50 AM
Bummer, LTO really isn't quite production just yet.  :lol:

After patching lto-1.exe with a hex editor to be LARGEADDRESSAWARE, I just about managed to build wxWidgets (multimedia and RTTI disabled) with LTO enabled before running out of address space. Kids, don't try this at home if your machine only has 4GB of physical memory. Linking (just linking, not the entire build!) took only about 45 minutes, too.  8)

Unluckily it still gives me missing symbols from wxWidgets when building Code::Blocks (and, funnily, only 2 of them when building c::b without LTO, but around 25 with LTO enabled for c::b). Seems something is just not right yet. Ah well, maybe with gcc 4.7...

Maybe you said this bug I ever reported:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49844

Then you can try -flto-partition=none  .

@TDragon
I suggest you to build ld and lto1 using -Wl,--large-address-aware.
This can solve many memory exhausted problems.

Quote from: xunxun1982 on October 06, 2011, 03:44:56 AMThen you can try -flto-partition=none

Tried, thanks... did not help though, unluckily.

I can only successfully build Code::Blocks with MingW-gcc 4.6.1 without LTO at all (except for Tinyxml and Squirrel/SQPlus). Anything remotely close to wxWidgets in any way blows up and burns. And, although it builds without LTO, it still doesn't run (error 0xc0000005 at startup).

Funnily, I can build wxWidgets with MingW-gcc 4.6.1 and then Code::Blocks with MingW-gcc 4.5.3 using that DLL just fine, and it works...

Has anyone tried using the sjlj version? Maybe it's some interaction with DW2 too, who knows. I'm only ever using DW2 ("DW2 or bust!"), so that might be it.

Quote from: thomas on October 07, 2011, 02:04:51 PM

Quote from: xunxun1982 on October 06, 2011, 03:44:56 AMThen you can try -flto-partition=none

Tried, thanks... did not help though, unluckily.

I can only successfully build Code::Blocks with MingW-gcc 4.6.1 without LTO at all (except for Tinyxml and Squirrel/SQPlus). Anything remotely close to wxWidgets in any way blows up and burns. And, although it builds without LTO, it still doesn't run (error 0xc0000005 at startup).

Funnily, I can build wxWidgets with MingW-gcc 4.6.1 and then Code::Blocks with MingW-gcc 4.5.3 using that DLL just fine, and it works...

Has anyone tried using the sjlj version? Maybe it's some interaction with DW2 too, who knows. I'm only ever using DW2 ("DW2 or bust!"), so that might be it.

It's very strange.
May you try my 4.6.1 edition (also dw2) https://pcxprj.googlecode.com/files/MinGW_gcc4.6.1release_static_win32.7z?
I haven't found these issues.

Quote from: thomas on October 07, 2011, 02:04:51 PM
Has anyone tried using the sjlj version? Maybe it's some interaction with DW2 too, who knows. I'm only ever using DW2 ("DW2 or bust!"), so that might be it.

So, I tried building wxWidets and C::B on Windows 7 with TDM 4.6.1 sjlj. It works nearly perfectly, only the NassiShneiderman plugin refuses to load. However, it's not an SDK mismatch issue (as C::B complains).

Ps.: Yes, I finally updated my platform from XP. ;-)

Quote from: MortenMacFly on October 09, 2011, 02:34:05 PM
It works nearly perfectly, only the NassiShneiderman plugin refuses to load.

I believe that is a symptom of the problem I described here (http://forums.next.codeblocks.org/index.php?PHPSESSID=m383k626h2hdvb2pknid30gab4&topic=15263.msg102980;topicseen#msg102980).

In the NassiShneiderman project file, change the linker option -enable-auto-import to -Wl,-enable-auto-import.

#include <float.h> can not include the mingw32's float header
please check with the macros for "Control word masks for unMask"

Quote from: lvdong on October 18, 2011, 06:25:24 AM
#include <float.h> can not include the mingw32's float header
please check with the macros for "Control word masks for unMask"

...what ever that means. :shock: Is this related to the compile failure? Because the "fix" of Alpha was correct.

i think he refers to an old gcc bug with mingw.
gcc's float.h collides with the one from mingw's.
several fixes on that one through time but it does rear its ugly head from time to time most notably when a new version of gcc hits the fan :/
It will probably newer be fixed 100% because the gcc team has made clear that they dont support changing it locally because it would break linux builds.

Quote from: reckless on October 18, 2011, 01:57:55 PM
i think he refers to an old gcc bug with mingw.
gcc's float.h collides with the one from mingw's.
several fixes on that one through time but it does rear its ugly head from time to time most notably when a new version of gcc hits the fan :/
It will probably newer be fixed 100% because the gcc team has made clear that they dont support changing it locally because it would break linux builds.

sorry for my pool english, you can check the following codes

source: a.c


#include <stdio.h>
#include <float.h>

#ifndef MCW_EM
#define MCW_EM _MCW_EM
#endif

int main()
{
    printf("%x\n",MCW_EM);
    return 0;
}


cmd: gcc a.c

tdm-gcc-4.5.2: pass
tdm-gcc-4.6.1: a.c:10:19: error: '_MCW_EM' undeclared

Aye thats pretty much the same error i ran into the couple of versions of gcc i been using with mingw when something used those float functions.
And a few others i cant remember of the top of my head.
Only advise i can give is let the mingw developers know that its broken (again) with 4.6.1 and hopefully they fix it for this version.

Quote from: reckless on October 19, 2011, 10:39:39 AM
Aye thats pretty much the same error i ran into the couple of versions of gcc i been using with mingw when something used those float functions.
And a few others i cant remember of the top of my head.
Only advise i can give is let the mingw developers know that its broken (again) with 4.6.1 and hopefully they fix it for this version.

I think gcc 4.6.1 with mingw64 headers and crt has not the issue.

Been a while since i had code using the float functions but an easy test is compiling QT 4.7 since i know it uses them.
Might be allready fixed with the mingw64 crt but cant speak for standard mingw crt.

Is it possible the backport this patch to 4.6.x serial of tdm gcc. see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

Mentioned here:http://forums.next.codeblocks.org/index.php/topic,15264.msg103631.html#msg103631

Without this fix, it was really annoying when debugging.
Thanks.

...did anyone try to link against bfd on 64 bit Windows? It seems the bfd library provided with the 64 bit version of TDM-GCC is incompatible. Is that correct?

Backported the patch to 4.6.2 it should allready be in on 4.6.3.
Havent tried linking to bfd with TDM's build since i maintain my own fork so cant say.
You are welcome to test my own fork and see if it also fails with that.
If it does let me know so it can be fixed.

the 64 bit fork is here. http://sourceforge.net/projects/cbadvanced/files/MinGW64-gcc-4.6.2-ada-build.7z/download (http://sourceforge.net/projects/cbadvanced/files/MinGW64-gcc-4.6.2-ada-build.7z/download)

Quote from: reckless on February 24, 2012, 08:08:57 AM
the 64 bit fork is here. http://sourceforge.net/projects/cbadvanced/files/MinGW64-gcc-4.6.2-ada-build.7z/download (http://sourceforge.net/projects/cbadvanced/files/MinGW64-gcc-4.6.2-ada-build.7z/download)

I don't need ADA, just C, C++ and GFortran. Do you have such, too? And BTW: Why are the packages so HUGE? GCC-TDM is 350MB uncompressed, while yours are 650MB and more compressed... :o

its not just ada its everything besides java and also the dragonegg compiler plugin. and sorry about the size im not sure why my builds end up bigger than TDM's maybe optimization related ? i use -O2. Ill see if i can strip the builds some to get sizes down.

ow forgot the two mingw packages where built by request for quake compilation and include a ton of libraries so thats why they are so large.
i made two minimal versions with just the gcc related libraries. you might like the size of those better.

http://sourceforge.net/projects/cbadvanced/files/mingw64-gcc-4.6.2-dragonegg-minimal.7z/download (http://sourceforge.net/projects/cbadvanced/files/mingw64-gcc-4.6.2-dragonegg-minimal.7z/download)

Quote from: reckless on February 24, 2012, 01:48:41 PM
http://sourceforge.net/projects/cbadvanced/files/mingw64-gcc-4.6.2-dragonegg-minimal.7z/download (http://sourceforge.net/projects/cbadvanced/files/mingw64-gcc-4.6.2-dragonegg-minimal.7z/download)

OK - I tried that, but that's not exactly what I am looking for. I am looking for the MinGW 64 compiler that can run / link on Win32 but "cross-compile" to Win64. The one in your archive only runs on 64 bit platforms. What I *could* do though is using the libraries provided with your compiler to link against - but that will be error-prone as the compiler I am using for the build differs (GCC-TDM).  :-\

Thanks for the effort anyways though...

Quote from: MortenMacFly on February 23, 2012, 05:02:14 PM
It seems the bfd library provided with the 64 bit version of TDM-GCC is incompatible. Is that correct?

This is correct; the libbfd that comes with TDM-GCC's binutils is 32-bit only. What in particular do you need libbfd for?

Quote from: TDragon on February 24, 2012, 07:18:01 PM
This is correct; the libbfd that comes with TDM-GCC's binutils is 32-bit only. What in particular do you need libbfd for?

Thanks for the info. I want to create a 64 bit version of our crash handler (exchndl). I stripped it down to this library dependency.

Good to know. I'll try and see about having both 32-bit and 64-bit versions for the next release. In the meantime, any Windows 64-bit version of libbfd should work; you could even build it yourself.

Quote from: TDragon on February 24, 2012, 07:39:31 PM
In the meantime, any Windows 64-bit version of libbfd should work; you could even build it yourself.

Good to know for me. In fact I tried the one shipping with the "official" MinGW/64 GCC but I wasn't sure if I am not doing anything wrong here, because the header files differ from the one of your distribution (namely ansidecl.h, bfd.h and bfdlink.h).

np m8 :) and aye my builds are non cross and intended for native builds so tdm's would suit better.
I dont think a lot changed in the bfd library since 4.6.1 so try it out it might work.

@MortenMacFly

You can try MinGW64 project X64 edition:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/

Quote from: reckless on February 24, 2012, 12:36:59 PM
its not just ada its everything besides java and also the dragonegg compiler plugin. and sorry about the size im not sure why my builds end up bigger than TDM's maybe optimization related ? i use -O2. Ill see if i can strip the builds some to get sizes down.

I think you use LTO to build all your packages? Or not strip your packages?

Quoteow forgot the two mingw packages where built by request for quake compilation and include a ton of libraries so thats why they are so large

Had forgotten the above  ::)  i compile with  -O2 -s -ftree-vectorize.

Quote from: xunxun on February 25, 2012, 04:05:03 AM
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/

Yes, I stumbled across, these, too. But I don't understand what I need to d/l at best (what is rubenvb, sezer, megasoft78 etc...)? Not to forget what a the differences between "Multilib Toolchains","personal builds" and "automated builds", what is official, what is not...

In my opinion there is just too much of different resources scattered in this download section without explanation. Not offending here, but if I look at TDM's releases, they are just clear and easy to understand / pickup.

Aye it can be a bit confusing. Multilib builds are like TDM's cross version but with a different layout.
Automated builds are just buildbot builds of there versions.
Sezero etc. Are personal builds with fixes to some problems (or) general improvements to the standard distros.
For instance the ada build has been on the backburner for years because of problems building gnat on windows with mingw64. Turned out the fix was an old TDM patch :).

GCC is now stable at version 4.7.0.
When can we expect a TDM-GCC release based on GCC 4.7.0? :)

Hopefully soon. :)

 ;D

Quote from: ptDev on April 09, 2012, 09:28:15 AM
GCC is now stable at version 4.7.0.
When can we expect a TDM-GCC release based on GCC 4.7.0? :)

I think TDM is better to build 4.7 when the bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 is fixed. The bug can prevent WebKit from building.

And at present, 4.7 can't build Code::Blocks trunk : http://forums.next.codeblocks.org/index.php/topic,16039.0.html  
Hope Jens will fix it soon.

Neither of these are actual reasons against a TDM 4.7 build, if you ask me.

The Code::Blocks (or rather Squirrel) issue is not GCC's fault, it's code relying on non-conforming behaviour that breaks. The new behaviour is correct.
The WebKit issue seems to be a GCC bug indeed, but one that will only affect few people. On the other hand, the new version has a lot of very useful and eagerly anticipated features, which in my opinion by far outweight the sporadic bugs.

Frankly, as long as GCC doesn't break any Objective-C features and continues to improve the runtime, I see no problem with the newest release, bugs and all.

any news on the gcc 4.7.0 ?
im really eager to get my hands on it using TDMs build :)
and thank you for your great work :)

Not TDM's but uses some of his patches.

http://sourceforge.net/projects/cbadvanced/files/gcc32-4.7.0.7z/download (http://sourceforge.net/projects/cbadvanced/files/gcc32-4.7.0.7z/download)
http://sourceforge.net/projects/cbadvanced/files/gcc64-4.7.0.7z/download (http://sourceforge.net/projects/cbadvanced/files/gcc64-4.7.0.7z/download)

Very hard to build on windows atm due to some bugs with detection of system headers, bootstrapping is a complete nogo so this is a non bootstrap build.
Builds contain ada support for both 32 and 64 bit arch.

Quote from: reckless on April 17, 2012, 06:36:01 AMVery hard to build on windows atm

Heh, as if building gcc had ever not been a total pain in the ass.  ::)

But, if it's even more borked than usual, that's no good news.

Aye newer been easy but now its just silly :S stage 1 works but in stage 2 it looses track of system headers and states that there are none no matter where you put em lol  ::)
it also refuses to build libcpp unless you make a hardcopy of cpp.exe in /usr/lib...
From testing i can say that C works fine but C++ seems to have some weird behaviour compared to earlier releases (cannot build C::B without -fpermissive and the patch for squirrel for one and the executable crashes with 0x00005 error). Atleast the header composition bug was posted so might be fixed sometime soon. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947)

See, that's what I'm always saying about the downsides of universality, portability and localization, and all that stuff.

Gcc builds on what, 50 different host architectures, for 25 targets, with cross and whatnot, and handles what, 20 programming languages and output in 30 character sets and 135 languages? Great.
However, you cannot get it to build on the single most common host in the world, for the single most common host/target combination, with the two most used languages.  ::)

Though I have to admit that I once managed, after burning weeks of time, to get a 3/4 build (cross, from Debian) done. Except 3/4 through the build is as good as 0/4   8)

Just a heads up for john if he works on 4.7.0 the shmem patch needs to be modified a bit since the stuff it changes has moved into the libgcc folder. Also a few of the names where changed. I got it fixed and it compiles ok.

If you'd like to attach or PM me the modified version, I'll compare it to mine to see if I missed anything. :)

pm'ed the modfied patch not sure if you noticed it yet ?.

i removed the magic you had in libstdc++ makefile.in because it needs to be modified as well (now 3 seperate libraries instead of one in libsupc++ gets linked into the final libsupc++ library). It works ok without it but i guess you had your reasons to split it up in seperate shared/static elements.

Unfortunatly anything linking to libstdc++ will crash on win7 64 (not sure if it also does so on Win7 32) but its not related to your patch the unmodified version also crashes.
This affects both static and shared builds so its really a bug in libstdc++. As an experiment try replacing something that was linked to the shared libstdc++ with the libstdc++ dll from a previous version. With the gcc-4.7.0 libstdc++ i get the application has stopped working but if i replace it with the gcc-4.6.3 one it works.