User forums > General (but related to Code::Blocks)

TDM-GCC 4.5 series (Latest: 4.5.2 - 2011-03-27)

<< < (15/23) > >>

MortenMacFly:

--- Quote from: TDragon on September 02, 2010, 06:09:31 am ---TDM-GCC 4.5.1 is now available!

--- End quote ---
Great news, as usual. What about the underscored in the fortran world? Because I've many code that actually adds the underscore when using C (C++) and Fortran together. Would that mean I don't need these patches anymore? ...I'll simply try... ;-)

TDragon:
MortenMacFly:
The underscoring change only affects 64-bit compilation. Your mileage may vary.

Everyone:
I've released patch 2 of the TDM64 runtime package which fixes a TDM-GCC-introduced bug in the inclusion of <float.h>.

ArbolOne:
I just got a new Win7-64; I proceeded to download/install  TDM-GCC Compiler Suite for Windows, having done that I continued with the installation of CodeBlocks. I am currently trying to compile a simple "Hello" program, but to no avail. I get this error message:
======
"testingCB - Debug" uses an invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!]. Probably the toolchain path within the compiler options is not setup correctly?! Skipping...
Nothing to be done.
======
However, the MinGW64/bin directory has been added to the "%path%" (twice!), once by the installer and once by me.
In an attempt to resolve this issue, I have change the toolchain in the "Settings->Compiler/Debugger->Toolchain Executables"  from the default "gcc" to "x86_64-w64-mingw32-gcc.exe". I did the same with the g++'s entries. But this did not change anything.

What am I doing wrong?
Can anybody help?

TIA

TDragon:

--- Quote ---Probably the toolchain path within the compiler options is not setup correctly?!

--- End quote ---
Thank you for failing to read --

* the TDM-GCC README,
* Code::Blocks documentation,
* Code::Blocks' own compiler settings dialog, and
* the error message right before your eyes!You've really made my day.

thomas:
Thank you for including LTO as well, John :)

Unluckily, LTO seems to still have some considerable problems. I've tried recompiling Code::Blocks with -flto. The first observation is that building takes approximately 8-10 times as long (which isn't a real issue to me if it's orthogonal -- you can do cheap builds during development and run one super expensive build with -flto added before release, which is perfectly acceptable as a one-time thing for a better optimized final build).

The second, much more severe issue is that the linker chokes on classes that have inline virtual destructors, complaining about double definitions. It also seems to have issues with classes which are derived from a virtual base class that do not provide an instance of the virtual destructor. Adding an instance (in a source file) removes the problem.

I started implementing a workaround for the Code::Blocks sources, but unluckily there are classes within wxWidgets (e.g. wxMemoryDC) which have the very same properties, and sure enough the compiler chokes on them too, so a functional workaround would require patching and recompiling wxWidgets :(

Well, looking forward to the next release with hopefully improved LTO :)

By the way, is there a way to make windres a bit less stupid? It seems to have hardcoded gcc.exe in its guts and apparently cannot be convinced by any means to invoke anything different, which of course means that it will consistently fail if the binary is named gcc-dw2.exe, both when building wxWidgets and anything that uses resources otherwise. The obvious workaround is to make a copy of the binary, but although this works, it is really less than optimal considering that it's only this one stupid tool which is not working right.
All other programs in the toolchain "know" the correct names of their siblings and can also be told to use arbitrary different names by setting CC, CPP, and CXX... only windres, is so f...ing stupid and stubborn.

Navigation

[0] Message Index

[#] Next page

[*] Previous page