Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Building C::B with MinGW64

<< < (5/5)

eranon:
OK, succeeded to build wxWidgets 2.8.12 DLL 32-bit (thanks to Xaviou : http://forums.wxwidgets.org/viewtopic.php?f=23&t=37920). Then, I've restarted from C::B SVN from scratch (I mean, new check-out to be sure), launched codeblocks.workspace in my C::B Nightly Build, checked the binded compiler/linker settings well contains -m32 and the equivalent about windres, and clicked Rebuild Workspace. CobeBlock were built without problem and I ran update.bat. I've copied the wxmsw28u_gcc_custom.dll beside output/codeblocks.exe (now both compiled with the same compiler coming from MinGW64)... And I get the same error 0xc000007b at launching, the application didn't started properly. So, now, I try to figure out if MinGW64 requires a mingwm10.dll or not (and if yes, where could I find it).

If you have an idea, don't hesitate...

--
EDIT : it sounds like mingwm10.dll is not needed anymore with MinGW64

eranon:
Solved :)

Reading this thread http://forums.codeblocks.org/index.php?topic=12635.0, I had a look at the embedded manifest in codeblocks.exe and seen it indicated :


--- Code: ---processorArchitecture="amd64"
--- End code ---

So, I've extracted it (using mt.exe), changed the wrong declaration by "x86", then rembedded it (overwriting the previous in codeblocks.exe). And that was it :o

Huki:
I have a 32-bit PC, but as the mingw-w64 project has a more complete win32api and python gdb support, I recently switched to it. I downloaded the official mingw-builds version (x32-4.8.1-posix-dwarf-rev2), not TDM. I used it to compile both wxWidgets 2.8 and C::B trunk, and contrib plugins (excluding Nassi S). A few points to note:
- Need to use plain ar.exe for static libs.
- No mingwm10.dll dependency, rather the posix version uses libwinpthread (which can be static linked if required, see below).
- -static flag needs to be specified for static linking of libgcc, libstdc++, etc.
- wxWidgets compiling will pump out a lot of warnings unless -Wno-unused-local-typedefs is specified.

An interesting thing I noticed is that, with dwarf exception handling the Code Completion full project parsing times are over twice as fast compared to sjlj. :o

Navigation

[0] Message Index

[*] Previous page