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.
This seems to be your problem: http://sourceware.org/bugzilla/show_bug.cgi?id=12762That'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.
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 :)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.
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'#ifndef __OBJC__
#ifndef interface
#define interface struct
#endif
#endif// ObjC compatibility hack
#ifdef __OBJC__
#define __OBJC_WAS_DEF__ __OBJC__
#undef __OBJC__
#endif
// ObjC compatibility hack
#ifdef __OBJC_WAS_DEF__
#define __OBJC__ __OBJC_WAS_DEF__
#undef __OBJC_WAS_DEF__
#undef interface
#endif
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
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").
Unluckily, this build rejects pretty much every piece of code I've ever written with multiple definition ofYou can use latest binutils snapshot.
`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.
Bummer, LTO really isn't quite production just yet. :lol:Maybe you said this bug I ever reported:
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...
Then you can try -flto-partition=noneTried, thanks... did not help though, unluckily.
It's very strange.Then you can try -flto-partition=noneTried, 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.
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).
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.codeblocks.org/index.php?PHPSESSID=m383k626h2hdvb2pknid30gab4&topic=15263.msg102980;topicseen#msg102980).
#include <float.h> can not include the mingw32's float header...what ever that means. :shock: Is this related to the compile failure? Because the "fix" of Alpha was correct.
please check with the macros for "Control word masks for unMask"
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.
#include <stdio.h>
#include <float.h>
#ifndef MCW_EM
#define MCW_EM _MCW_EM
#endif
int main()
{
printf("%x\n",MCW_EM);
return 0;
}
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.I think gcc 4.6.1 with mingw64 headers and crt has not the issue.
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.
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
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). :-\
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?
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.
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).
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
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...
GCC is now stable at version 4.7.0.
When can we expect a TDM-GCC release based on GCC 4.7.0? :)
Very hard to build on windows atmHeh, as if building gcc had ever not been a total pain in the ass. ::)