Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
How to compile Code::Blocks 20.03 in 32-bit mode with TDM-GCC
SiZiOUS:
Hello there,
Finally, I successfully compiled C::B 20.03, in 32-bit and 64-bit mode using TDM-GCC-64. It was not straightforward at all. I got several issues for doing that.
First of all I'm still using TDM-GCC-64 but this applies on MinGW-w64 as well. Of course as you might know, TDM-GCC-64 is based on MinGW-w64 which can target both x86 and x64 binaries. I can't use TDM-GCC-32 because this one is based on the old MinGW project which is outdated (e.g. it doesn't include some required files like for enabling Direct2D) so using this project isn't an option. Despite of their names, MinGW and MinGW-w64 are completely separated projects.
So my initial issue was, when I was compiling C::B 20:03 in 32-bit mode from my Windows 7 x64 VM, all the produced x86 binaries were showing the following error: STATUS_INVALID_IMAGE_FORMAT (0xc000007b). As I stated from the beginning, this issue was caused when 32-bit binaries try to load 64-bit libraries. But I didn't understand why this happened... until now.
I noticed after that some compiled 32-bit binaries ... were actually working. These binaries were the one with no embedded resources (i.e. compiled with windres). So when I explored in deep the resources of these executables, I saw the issue: the manifest embedded in the executables were forcing the compiled 32-bit binaries to load 64-bit libraries...
So after investigating a lot, I saw that the generated rcdefs.h file when compiling wxWidgets was wrong. The WX_CPU_AMD64 directive was incorrectly added in the file... because my OS is actually a x64 OS. That's the reason why the x64 manifest was added to x86 binaries.
The fun fact is, I was using the wx 3.1.3, and this bug has been fixed in 3.1.4... as you may see here. So I fixed my working copy of wx 3.1.3 with the provided patch in that ticket and now, I got the WX_CPU_X86 define in the rcdefs.h so it's OK.
So, it was working for all the produced 32-bit binaries except... C::B itself. Pretty confusing... because for all produced binaries it was working but C::B still embed the x64 manifest!
So I've checked the codeblocks/src/src/resources/resources.rc file and then I saw this:
--- Code: (javascript) ---///////////////////////////////////////////////////////////////////////////////
// Specify the processor architecture (wxWidgets seems not to do this correctly)
#if defined(_M_AMD64)
#if defined(WX_CPU_X86)
#undef WX_CPU_X86
#endif
#if !defined(WX_CPU_AMD64)
#define WX_CPU_AMD64
#endif
#elif defined(_M_IA64)
#if defined(WX_CPU_X86)
#undef WX_CPU_X86
#endif
#if !defined(WX_CPU_IA64)
#define WX_CPU_IA64
#endif
#elif defined(_M_IX86) || defined(_X86_)
#if !defined(WX_CPU_X86)
#define WX_CPU_X86
#endif
#endif
--- End code ---
Like the first comment say here, it's perfectly true. When using windres, the WX_CPU_AMD64 value was still used, even if the WX_CPU_X86 define was put in rcdefs.h! But even worse, the C::B team integrated the code above which create that double issue (I mean: the original, failback rcdefs.h was computing the WX_CPU_AMD64 define incorrectly since my OS is x64, and the C::B team added a copy of this detection on this resource.rc file).
Then after come the second fix: the include order was actually wrong defined in the projects. In fact, the rcdefs.h file is generated when compiling wx but there is a failback rcdefs.h file in the "include" directory. Because of this, the wrong rcdefs.h file was used which defined WX_CPU_AMD64 for my x86 wx binary, instead of WX_CPU_X86.
So I needed to change on all C::B projects the include order to fix that.
As you might see here, the highlighted row should be set before the standard wx include dir in order to take into account the generated rcdefs.h file. So just use the top arrow button on the right to switch the order of includes.
After that, I setup a new GCC Compiler with my x86 switches (i.e. the famous -m32 switch). And now, I'm able to compile both x86 and x64 C::B 20.03 release from my Windows x64 computer.
If you are interested I can write a how-to telling all the steps for compiling C::B in both x86 and x64 flavours using TDM-GCC-64.
stahta01:
So, you succeeded, that is good. I wonder whether in a year or two you will considered it a useful use of your time.
Me, I would likely have taken the easy route of using an MinGW64 GCC 32 bit build.
Tim S.
SiZiOUS:
Hello,
So I did have some troubles by using the TDM-GCC compiler for building Code::Blocks 64-bit (everything is fine with 32-bit).
Indeed, when compiling in 64-bit flavour with TDM-GCC-64 (as it should be), all the wx produced programs just crashes at the exit directly in the wx runtime library.
I did post a subject on the wxWidgets library forum and now it works.
In summary, what I did for recompiling the Code::Blocks 20.03 source code for Windows, on both 32-bit and 64-bit flavours:
* I fixed the C::B source code like I described in this thread (important).
* I did some bug fixes in the wx 3.1.3 library (back-porting some changes from 3.1.4 to 3.1.3).
* Then I compile the project:
* For 32-bit: I use TDM-GCC-64 with the -m32 switch like described here (Why? TDM-GCC-32 uses MinGW.org toolchain as base and this project is outdated, it doesn't includes some recent headers like the one for enabling Direct2D; when TDM-GCC-64 is based on MinGW-w64 and it includes everything needed)
* For 64-bit: I use the Nuwen 16.1 toolchain. Don't try to use a more recent Nuwen toolchain, OR if you do so, you have to migrate the wx library from 3.1.3 to 3.1.4.If you are curious, this is my repository which contains everything for building a working copy of C::B 20.03 on Windows, on both 32-bit and 64-bit releases. This repo includes some addition I made as my C::B release is improved for supporting the Sega Dreamcast platform.
oBFusCATed:
@SiZiOUS: I'm not sure what is the goal of your post, but if you want to contribute changes to codeblocks it is best to post patches in https://sourceforge.net/p/codeblocks/tickets/ (starting pull requests on my repo in github is also acceptable). I've skimmed the wxwidgets topic and I didn't see anything looking like a patch.
Anaflion:
--- Quote from: SiZiOUS on October 15, 2020, 11:03:08 pm ---
If you are interested I can write a how-to telling all the steps for compiling C::B in both x86 and x64 flavours using TDM-GCC-64.
--- End quote ---
Hello!
Yes, please. If You would!
I compiled my app and statically links and it x64 with libs by TDM-GCC and now i should make statically linked app x32.
Navigation
[0] Message Index
[*] Previous page
Go to full version