User forums > Help
problems with 32-bit executables in TDM mingw64 installation
MortenMacFly:
--- Quote from: bootstrap on July 02, 2012, 11:21:57 am ---I attach the project files, including the project and all the directories and such, complete with object files and executables.
--- End quote ---
Al-right, with the project you've attached I cannot reproduce the error. I tried compiling all with TDM's 64 bit compiler - this works. Another trial with compiling the 32bit versions using the 32bit version of TDM and 64bit with 64bit version of TDM (which is my usual config) works, too. ???
Maybe you have screwed your compiler installation(by overwriting files during an update) or you have stuff in the PATH environment that does not belong there?
Try a full clean re-install of TDM's compiler.
bootstrap:
--- Quote from: MortenMacFly on July 02, 2012, 03:06:15 pm ---
--- Quote from: bootstrap on July 02, 2012, 11:21:57 am ---I attach the project files, including the project and all the directories and such, complete with object files and executables.
--- End quote ---
Al-right, with the project you've attached I cannot reproduce the error. I tried compiling all with TDM's 64 bit compiler - this works. Another trial with compiling the 32bit versions using the 32bit version of TDM and 64bit with 64bit version of TDM (which is my usual config) works, too. ???
Maybe you have screwed your compiler installation(by overwriting files during an update) or you have stuff in the PATH environment that does not belong there?
Try a full clean re-install of TDM's compiler.
--- End quote ---
I uninstalled TDM64, deleted the remaining [empty] mingw64 directory tree, then fresh installed TDM64 again. I then started codeblocks and tried to debug the windoze32_debug target, but the behavior has not changed?
Is there any point in removing and re-installing codeblocks too? My codeblocks installation was from file <codeblocks_20120617_rev8059_win32.7z>.
BTW, did you find the project settings to be okay?
I guess the next question will be, do I have the toolchain set incorrectly, or the search path, or something else? Under settings => compiler => toolchain-tab, I select executables in the <c:/mingw64/bin> directory. Is that correct? Also, the path for all targets is <c:/mingw64/x86_64-w64-mingw32/include>. I don't specify a search path for libraries. Should I ??? What other setting might I have wrong?
MortenMacFly:
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---BTW, did you find the project settings to be okay?
--- End quote ---
Yes, otherwise I wouldn't have been able to compile your project.
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---I guess the next question will be, do I have the toolchain set incorrectly, or the search path, or something else?
--- End quote ---
As I said: I have both: The 32 bit and the 64 bit TDM compiler installed. Then the only change I made in the compiler options is that I setup the toolchain path and only for the 64bit compiler added under "other compiler options":
-fno-keep-inline-dllexport
-m64
...and under "other linker options" I added :
-m64
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---Under settings => compiler => toolchain-tab, I select executables in the <c:/mingw64/bin> directory. Is that correct?
--- End quote ---
No. There is a message saying that you have to set the root folder (!), so, c:/mingw64. C::B will look into the bin folder automatically. The reason is that C::B can only "compute" the default include and lib path, if the root path is known.
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---Also, the path for all targets is <c:/mingw64/x86_64-w64-mingw32/include>.
--- End quote ---
That's wrong, too. You should not need to setup any include folder there, especially not this one.
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---I don't specify a search path for libraries. Should I ???
--- End quote ---
No. All it needs is the compiler's root folder. Don't fiddle with other settings if you are unsure.
bootstrap:
--- Quote from: MortenMacFly on July 03, 2012, 07:48:58 am ---
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---BTW, did you find the project settings to be okay?
--- End quote ---
Yes, otherwise I wouldn't have been able to compile your project.
--- End quote ---
--- Quote ---
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---I guess the next question will be, do I have the toolchain set incorrectly, or the search path, or something else?
--- End quote ---
As I said: I have both: The 32 bit and the 64 bit TDM compiler installed. Then the only change I made in the compiler options is that I setup the toolchain path and only for the 64bit compiler added under "other compiler options":
-fno-keep-inline-dllexport
-m64
...and under "other linker options" I added :
-m64
--- End quote ---
Let me make sure I understand. I only have the 64-bit TDM package installed (the one I mentioned in my original message), which says it can build both 32-bit and 64-bit targets. But you have separate 32-bit and 64-bit TDM packages installed, presumably because you try to support us morons out here in the wilderness, and therefore want to be able to test the same configurations we have.
--- Quote ---
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---Under settings => compiler => toolchain-tab, I select executables in the <c:/mingw64/bin> directory. Is that correct?
--- End quote ---
No. There is a message saying that you have to set the root folder (!), so, c:/mingw64. C::B will look into the bin folder automatically. The reason is that C::B can only "compute" the default include and lib path, if the root path is known.
--- End quote ---
I see. However, as part of my attempt to get everything working, I went down to each tool, one by one, clicked the "..." button, and browsed to the tool in the c:/mingw64/bin directory. So no matter what I had set as the default search path for the tools, I assume this made sure the correct tools were being executed. Or could this approach perhaps have caused me some troubles?
--- Quote ---
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---Also, the path for all targets is <c:/mingw64/x86_64-w64-mingw32/include>.
--- End quote ---
That's wrong, too. You should not need to setup any include folder there, especially not this one.
--- End quote ---
Okay, I'll fix that.
--- Quote ---
--- Quote from: bootstrap on July 03, 2012, 03:58:22 am ---I don't specify a search path for libraries. Should I ???
--- End quote ---
No. All it needs is the compiler's root folder. Don't fiddle with other settings if you are unsure.
--- End quote ---
Wow, I got one thing right.
I'll try again as soon as I get my windoze7 system running again. Unfortunately, as has become extremely common lately, I seem to be victim of macroshaft nastiness --- or possibly something else very strange. I noticed the 4-core phenom2 CPU in my windoze system wasn't capable of AVX, which I need (wrote lots of AVX assembly on my linux system, which is much faster than the old SSE4+ code). So I bought a new motherboard and 8-core FX8150 CPU to make my windoze computer identical to my linux computer. Unlike the older versions of windoze I've had, windoze7 would not boot up the slightly different hardware (newer gigabyte motherboard, newer phenom2 CPU, but otherwise pretty much the same). It offered to check for new hardware and boot up. Didn't work. Then I tried booting off the windoze7 install DVD to do the same. Didn't work. Booting off the DVD and trying to "repair" didn't work. Linux live DVDs boot and run fine on the system, so presumably the new motherboard and CPU are okay. It won't perform a fresh install either, probably because the original install was over my winxp64 drive, which now doesn't exist (to prove I was in fact performing an upgrade). I guess having a windoze7 installation isn't sufficient to upgrade? Freaking hell! I guess I'll have to create a bogus winxp64 installation just so I can re-install windoze7. Sigh, endless time-destroying hassles. Once I get past this windoze7 hassle, and have windoze7 up and running again, I'll get back to getting this work. Until then, a bit of a pause in the process. At least I can continue working on linux!
zabzonk:
Calling Windows "windoze" isn't funny, clever or original.
Navigation
[0] Message Index
[*] Previous page
Go to full version