Author Topic: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)  (Read 48536 times)

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #15 on: September 27, 2011, 10:33:23 am »
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
« Last Edit: September 27, 2011, 10:35:09 am by gd_on »
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #16 on: September 27, 2011, 10:47:55 am »
gd_on: Reread the announcement about the 64bit compiler. Read carefully the part where the compiler can produce both 32 and 64 bit binaries.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #17 on: September 27, 2011, 11:18:09 am »
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
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #18 on: September 27, 2011, 12:15:38 pm »
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
"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: 936
    • Twilight Dragon Media
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #19 on: September 28, 2011, 02:12:43 am »
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.
http://tdm-gcc.tdragon.net/ - TDM-GCC compiler suite for Windows (GCC 5.1.0 2015-06-28, 32/64-bit, no extra DLLs)

Offline Justin Brimm

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #20 on: September 28, 2011, 10:21:50 am »
Attempts to compile anything using the new version produces a multitude of errors, the first being:

Code: [Select]
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

Code: [Select]
#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:

Code: [Select]
// ObjC compatibility hack
#ifdef __OBJC__
#define __OBJC_WAS_DEF__ __OBJC__
#undef __OBJC__
#endif

At the end of windows.h, add:

Code: [Select]
// 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.
« Last Edit: September 28, 2011, 11:58:09 am by Justin Brimm »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #21 on: September 28, 2011, 02:53:10 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5239
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #22 on: September 28, 2011, 03:08: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
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 Justin Brimm

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #23 on: September 28, 2011, 07:04:24 pm »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #24 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...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline reckless

  • Regular
  • ***
  • Posts: 333
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #25 on: October 03, 2011, 09:32:23 pm »
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.

Offline Totoxa

  • Multiple posting newcomer
  • *
  • Posts: 31
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #26 on: October 04, 2011, 02:46:15 am »
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?

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #27 on: October 04, 2011, 08:30:02 am »
I had a similar problem, but for me the solution is in Tdragon's original post :
Quote
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").

It is necessary for me. Have you tried that ?

gd_on
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline xunxun

  • Almost regular
  • **
  • Posts: 187
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #28 on: October 06, 2011, 03:38:17 am »
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.
Regards,
xunxun

Offline xunxun

  • Almost regular
  • **
  • Posts: 187
Re: TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)
« Reply #29 on: October 06, 2011, 03:44:56 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  .
Regards,
xunxun