User forums > General (but related to Code::Blocks)
Installing 64bit?
oBFusCATed:
You need to change the compiler associated to the project/target you're trying to build.
b105xor:
--- Quote from: oBFusCATed on June 07, 2010, 02:48:33 pm ---You need to change the compiler associated to the project/target you're trying to build.
--- End quote ---
Yeah, I tried that and it didn't work. It is definitely a bug with C:B - here is the list of things I tried before I got it to work:
-copied old tools to new 64bit variant, modified path and exe's for new toolset.
-changed project to use new toolset
-build still used original toolset
-many C:B open/close cycles
-build still used original toolset
-deleted C:B and reinstalled
-build still used original toolset
-cycle power
-build still used original toolset
-deleted original toolset
-build still tried to use original toolset
-Changed toolset to watcom
-C:B complied and used Watcom for building
-Changed to new "copied" 64 variant of mingw64
-success
Finally then, it looks like 2 bugs:
1-uninstall doesn't clear Win7 registry settings
2-C:B will ignore a toolset change to a copied toolset unless you first transitioning through a pre-installed toolset.
Not trying to be critical though - it seems to be a great tool.
Jenna:
--- Quote from: b105xor on June 07, 2010, 04:37:46 pm ---Finally then, it looks like 2 bugs:
1-uninstall doesn't clear Win7 registry settings
2-C:B will ignore a toolset change to a copied toolset unless you first transitioning through a pre-installed toolset.
--- End quote ---
1 C::B do not use the library to save the configuration, so it cab not clear it.
2 C::B does not ignore toolset changings, at least not here (neither on linux nor on w2k, xp or vista, not tested on win7).
You did not write which version of C::B you use, so it's difficult to give the correct answer.
If you have both toolchains in system-path (or at least the one you do not use actually) and one of the toolchains is incomplete (most likely the new one), you might use a mix of 32- and 64-bit tools.
If you have made any settings in Global compiler options for the original toolchain before copying it (search-paths, libs etc.) they get copied to the new one and can break it.
b105xor:
--- Quote from: jens on June 07, 2010, 05:10:57 pm ---
1 C::B do not use the library to save the configuration, so it cab not clear it.
2 C::B does not ignore toolset changings, at least not here (neither on linux nor on w2k, xp or vista, not tested on win7).
You did not write which version of C::B you use, so it's difficult to give the correct answer.
If you have both toolchains in system-path (or at least the one you do not use actually) and one of the toolchains is incomplete (most likely the new one), you might use a mix of 32- and 64-bit tools.
If you have made any settings in Global compiler options for the original toolchain before copying it (search-paths, libs etc.) they get copied to the new one and can break it.
--- End quote ---
I'm not sure this is going to be where you want to track bugs, but I am game if you are.
1-If C:B is not using the registry, then the bug is that C:B uninstall does not delete configuration files. The effect is the same - a final user should not have to reverse engineer the application to figure out how to uninstall it.
2-I changed absolutely nothing between my change from Mingw64 to Watcom and back to Mingw64 when it magically started working. It was not an issue of mixing toolchains. It was simply ignoring the new toolchain and all indications were to that effect (e.g. exe names are completely different in each toolset and in verbose mode C:B was shown invoking the old exe names - "path" can never enter into such an error). I did have an additional search and lib path which I was happy to see get duplicated in the new copy that I used for Mingw64. Can you be more specific about how this will "break" the new tool chain? I did see some unexpected tool path type error with the Mingw64 toolset when C:B started to use it (after the swap from Watcom).
In the interest of full discloser, I am not currently on the machine I was using when I saw these errors. However, I installed C:B on both within a few hours, on Saturday, so 99% they are the same, which is 10.05. If I get time, I might be able to recreate it on XP.
Thnx for the speedy reply!
b105xor:
I am trying to reproduce the previous behavior and I get very strange results. On this machine I have VS2005 and not Watcom and it is XP.
My MinGW64 gets completely ignored as before, but I tried swapping to VS2005 and oddly, C:B is building with MinGW. Very unexpected behavior. Fortunately, with VS2005, it gives some message that VS2005 is an invalid install or something is broken so it is ignoring VS2005 and compiling with MinGW! I mean, ok, its unexpected, so I am happy to have a message, but when I go back to the MinGW64, C:B ignores the MinGW6 exe's and does not give the nice message that it has arbitrarily picked a replacement compiler.
Obviously I would argue this is an unwanted behavior, but if this makes every one else happy then hey whatever. It looks like the bug is more about warning message not showing when a newly created toolset is rejected for some reason.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version