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