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

TDM-GCC 4.6 series (Latest: 4.6.1 - 2011-09-23)

<< < (4/15) > >>

gd_on:
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

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

gd_on:
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

thomas:
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

TDragon:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page