Print Page - Building C::B with MinGW64

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: daniloz on February 28, 2011, 08:54:18 pm

Title: Building C::B with MinGW64
Post by: daniloz on February 28, 2011, 08:54:18 pm

Can anyone successfully build the svn trunk version using MinGW64 on win7 ??

Any help would be much appreciated!

Title: Re: Building C::B with MinGW64
Post by: ironhead on February 28, 2011, 10:01:13 pm

I would very much like to get this going as well. The last time I attempted this it didn't go very well.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 19, 2013, 02:44:53 pm

+1
Interested too.

Title: Re: Building C::B with MinGW64
Post by: thomas on August 19, 2013, 04:35:00 pm

I tried that some weeks ago using a somewhat older build of Code::Blocks. Turned out there was no way of getting a complete build due to some bug (I forgot what exactly... Alpha would know) that caused 50,000 warnings and lots of build errors.

However, building trunk first with gcc-4.7-mingw32 and then building trunk again with gcc-4.8-mingw-w64 using that up-to-date build worked perfectly fine.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 19, 2013, 07:54:52 pm

Thanks for this feedback, thomas. Nice to know that, at least, a full build with MinGW32 then subsequent 32-bit build using MinGW64 has chance to pass. Of course, the best would be to be able to build C::B in 64-bit too, but I've read somewhere (really don't remember where precisely) some C::B devs are working on this subject.

Title: Re: Building C::B with MinGW64
Post by: MortenMacFly on August 20, 2013, 07:53:18 am

Quote from: daniloz on February 28, 2011, 08:54:18 pm

Can anyone successfully build the svn trunk version using MinGW64 on win7 ??

Yes, many times, including 2 days ago. At least the core and the core plugins work just fine. for the contrib plugins there are no project files (yet).

Title: Re: Building C::B with MinGW64
Post by: thomas on August 20, 2013, 12:27:30 pm

Quote from: eranon on August 19, 2013, 07:54:52 pm

Thanks for this feedback, thomas. Nice to know that, at least, a full build with MinGW32 then subsequent 32-bit build using MinGW64 has chance to pass. Of course, the best would be to be able to build C::B in 64-bit too, but I've read somewhere (really don't remember where precisely) some C::B devs are working on this subject.

Well, it's really a matter of too-old-build rather than MingW32/64. You can build CB perfectly fine in a w64 build using a w64 compiler, I last did this a week or two ago.

But since my suck-ass Atom Win8 tablet (what a total fuck-up combination, poor CPU, poor OS... but waht can you do) is 32bit, I'm now using a MingW-w64-32 build. This runs on both 32 and 64 bit systems with no disadvantages, and it's only wasting time once to build... it's not like one really needs a 64bit executable, there's no true difference.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 20, 2013, 02:35:01 pm

Hello,

Quote from: MortenMacFly on August 20, 2013, 07:53:18 am

Yes, many times, including 2 days ago. At least the core and the core plugins work just fine. for the contrib plugins there are no project files (yet).

I guess you're talking about x64 target here, Morten. I effectivelly see one project file only about a 64-bit build ("CodeBlocks_wx29_64.cbp" and not any workspace file) against wxWidgets 2.9.x. Well, at this time (and awaiting a full pre-made x64 workspace), I would be happy to succeed to build a 32-bit C::B using TDM64-GCC... Noted on my never done TODO list :)

Quote from: thomas on August 20, 2013, 12:27:30 pm

I'm now using a MingW-w64-32 build. This runs on both 32 and 64 bit systems with no disadvantages, and it's only wasting time once to build... it's not like one really needs a 64bit executable, there's no true difference.

I'm using a MinGW64_32 too (TDM64-GCC 4.7.1), thomas, and build both my own projects for 32 and 64-bit targets, so, using profiler, I've had time to compare... And the fact is that if there's not a big difference between a 32-bit build running under a 32-bit Windows and a 64-bit build running under a 64-bit Windows, it's not the case when the WoW64 layer (bottleneck) is involved (I mean when a 32-bit build is launched under a 64-bit Windows). I've even noticed that during wxWidgets compiling (building the 32-bit libs using MinGW64 takes two times the duration taken to build the 64-bit libs). And not talking about the addressability (available memory when you have an RAM consuming app).

--
EDIT : [moved to my next post]

Title: Re: Building C::B with MinGW64
Post by: thomas on August 20, 2013, 03:55:46 pm

Quote from: eranon on August 20, 2013, 02:35:01 pm

WoW64 layer (bottleneck)

It's true that the WoW64 layer adds some considerable overhead, especially when compiling or CC parsing (RtlInitializeExceptionChain, anyone?), and in particular because we create many more threads than would be necessary, which is extra expensive under WoW64. Unluckily, this is something we will have to live with for some time.

We have two half-working, broken platform implementations to replace the respective wxWidgets code, but getting them into a working, non-broken implementation is so far wishful thinking due to lack of time.

wxWidgets simply spawns one extra thread per process to listen on the pipe handles (or was it even one thread per pipe? I don't remember...). This works, but it also stinks.
Our half-working replacement implementations handle all pipes in one thread, and use WaitForMultipleObjects and select, respectively. Since there are 4 handles to watch per process, this however limits us to 16 processes maximum (also, the Unix implementation has a bug with return codes). Once upon a time when only few people had quad core processors, 16 concurrent processes seemed "huge", but with present time computers, this doesn't look like an implementation that we might want to publish.
Basically, what would be needed is an implementation around IOCP and epoll_wait/poll, which doesn't have such a limitation, and preferrably one that coalesces partial reads into single message blocks that are passed to the application after the process has exited (no use in having standard output tickle in "live" line by line as it is now, really -- every line currently creates one message which goes through the wxWidgets message system, including the 4 or 5 copies that are made during that process).

But sure enough, no time for approaching that before Christmas here, and even then I won't promise. Though maybe someone else is bored to death and wants to give it a try?

Quote

And not talking about the addressability (available memory when you have an RAM consuming app).

Well I don't know about the size of your projects, or anyone else's, but for me Code::Blocks very rarely uses more than 250 megabytes of committed memory, and I've never run out of address space. That said, VMMap tells me that Code::Blocks has 1.5GiB of free address space right now.
It's true that the linker will regularly run out of address space with LTO, but LTO is not really usable except for "hello world" anyway. At least for me it doesn't ever seem to work as soon as you link more than 2 libraries or have more than 10 source files...

The only program that I've ever used which truly needs 64 bits is WorldMachine, and once you generate maps which are that big, the recalculations become so painfully slow (as in, click "build" and go to lunch, and when you come back it still takes 2 hours) that you don't want to use it at all any more anyway.
The one big advantage of 64-bit mode is that you have twice as many registers. I've had some number crunching code speed up by 20 times due to that.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 20, 2013, 04:02:59 pm

Oop, I've published my build detail on an EDIT in my previous post while you posted your new message... Well, I'll move this EDIT in a new post and will reply to your own in a next one (it's easy;))

--
EDIT (moved from my previous post) : back on an attempt to build C::B 32-bit against wxWidgets 2.8.12 32-bit RELEASE (previously built with TDM32-GCC under Windows 7 32-bit) using TDM64-GCC under Windows 7 64-bit. Here is the useful part of my full build log (I've remove the cleaning part and detail of well compiled components) :

Code

-------------- Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is base\tinyxml\libtxml.a with size 120.17 KB

-------------- Build: AutoRevision in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is build_tools\autorevision\autorevision.exe with size 701.50 KB

-------------- Build: ConsoleRunner in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is tools\ConsoleRunner\cb_console_runner.exe with size 725.60 KB

-------------- Build: Squirrel in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is sdk\scripting\lib\libsquirrel.a with size 648.64 KB

-------------- Build: Squirrel std lib in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is sdk\scripting\lib\libsqstdlib.a with size 81.32 KB

-------------- Build: SqPlus in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is sdk\scripting\lib\libsqplus.a with size 72.27 KB

-------------- Build: scintilla in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

Output file is devel\libwxscintilla_cb.a with size 4.16 MB

-------------- Build: wxpropgrid in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler x86)---------------

g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\advprops.cpp -o .objs\sdk\wxpropgrid\src\advprops.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\editors.cpp -o .objs\sdk\wxpropgrid\src\editors.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\extras.cpp -o .objs\sdk\wxpropgrid\src\extras.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\manager.cpp -o .objs\sdk\wxpropgrid\src\manager.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\odcombo.cpp -o .objs\sdk\wxpropgrid\src\odcombo.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\propgrid.cpp -o .objs\sdk\wxpropgrid\src\propgrid.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\props.cpp -o .objs\sdk\wxpropgrid\src\props.o
g++.exe -Wall -O2 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DwxPG_SUPPORT_TOOLTIPS -iquote.objs\include -I.objs\include -I. -IC:\devlibs\wxWidgets-2.8.12\include -IC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Isdk\wxpropgrid\include -Iinclude -c X:\TMP\cb_svn_test\src\sdk\wxpropgrid\src\xh_propgrid.cpp -o .objs\sdk\wxpropgrid\src\xh_propgrid.o
g++.exe -shared  -Wl,--out-implib=devel\libwxpropgrid.a -Wl,--dll -Lbase\tinyxml -LC:\devlibs\wxWidgets-2.8.12\lib\gcc_dll .objs\sdk\wxpropgrid\src\advprops.o .objs\sdk\wxpropgrid\src\editors.o .objs\sdk\wxpropgrid\src\extras.o .objs\sdk\wxpropgrid\src\manager.o .objs\sdk\wxpropgrid\src\odcombo.o .objs\sdk\wxpropgrid\src\propgrid.o .objs\sdk\wxpropgrid\src\props.o .objs\sdk\wxpropgrid\src\xh_propgrid.o  -o devel\wxpropgrid.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined  -lwxmsw28u
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\devlibs\wxWidgets-2.8.12\lib\gcc_dll/libwxmsw28u.a when searching for -lwxmsw28u
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\devlibs\wxWidgets-2.8.12\lib\gcc_dll\libwxmsw28u.a when searching for -lwxmsw28u
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\devlibs\wxWidgets-2.8.12\lib\gcc_dll/libwxmsw28u.a when searching for -lwxmsw28u
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwxmsw28u
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 49 second(s))
1 error(s), 5 warning(s) (0 minute(s), 49 second(s))

To be sure I don't do an obvious mistake during the porcess, here it is :
1) Loaded CodeBlocks.workspace (under a C::B nightly beside, to be sure and even if I could use the C::B SVN already under output subdirectory)
2) Set the cb_release_type variable as "-O2" (wxWidgets 2.8.12 DLL being a RELEASE build too).
3) In case of, I've added the "-m32" option for compiler and linker (selecting all the project in the workspace, then build options in context menu)
4) Clicked "Rebuild all"

wxpropgrid seems to complain about wrong libwxmsw28u.a, but I don't know why...

Title: Re: Building C::B with MinGW64
Post by: stahta01 on August 20, 2013, 04:30:50 pm

Edited: Removed Quoted Text.

Please point to the location of the "-m32" in the compiler build log you posted.

Tim S.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 20, 2013, 05:09:24 pm

Quote from: thomas on August 20, 2013, 03:55:46 pm

It's true that the WoW64 layer adds some considerable overhead, especially when compiling or CC parsing (RtlInitializeExceptionChain, anyone?), and in particular because we create many more threads than would be necessary, which is extra expensive under WoW64. Unluckily, this is something we will have to live with for some time.

We're used to live with compromises ; human itself is not issue-free ::)

Quote from: thomas on August 20, 2013, 03:55:46 pm

We have two half-working, broken platform implementations to replace the respective wxWidgets code, but getting them into a working, non-broken implementation is so far wishful thinking due to lack of time.

[...]
But sure enough, no time for approaching that before Christmas here, and even then I won't promise. Though maybe someone else is bored to death and wants to give it a try?

Don't worry and thanks a lot for these accurate explainations, Thomas. Code::Blocks is already a best of, whatever be the TODO list... In fact, a project without TODO list is a dead project.

On my side, even if it's not x64 native just now, even if I'm wondering how to work around a specific behavior under wxSmith sometimes, even if we always want more and more... I stay with C::B/wxSmith for its long list of qualities ; and the cons will wait the required time (as Eisenhower said - if the story doesn't lie : "What is important is seldom urgent and what is urgent is seldom important").

Quote from: thomas on August 20, 2013, 03:55:46 pm

Well I don't know about the size of your projects, or anyone else's, but for me Code::Blocks very rarely uses more than 250 megabytes of committed memory, and I've never run out of address space. That said, VMMap tells me that Code::Blocks has 1.5GiB of free address space right now. [...]

It's true that the linker will regularly run out of address space with LTO, but LTO is not really usable except for "hello world" anyway. At least for me it doesn't ever seem to work as soon as you link more than 2 libraries or have more than 10 source files...

The one big advantage of 64-bit mode is that you have twice as many registers. I've had some number crunching code speed up by 20 times due to that.

My own projects are at human-level too, even if these days it would be not a marketing argument to say : my app consums a lot, and see, the exe is so big (LOL). I've often met people (not-software involved, of course, I mean) meaning that small is easier than big. So, what to say ? Nothing !

About build optimization (whatever be the stage, compile-time or linker one), there're so many branches and attempts to combinate speed, memory usage and quality of the output... Not so easy to decide what worth the effort or not...

"registers" : not so frequent to hear someone talking about registers these days... But, of course, I agree ; hoping the compiler generates the right intructions (I mean optimizing the use of underlying hardware) ;)

Title: Re: Building C::B with MinGW64
Post by: eranon on August 20, 2013, 05:27:59 pm

Quote from: stahta01 on August 20, 2013, 04:30:50 pm

Please point to the location of the "-m32" in the compiler build log you posted.

:o You're right ! I don't retrieve the -m32 neither in compiler nor linker options. So, my mistake (I guess I closed the dlg with cancel, really don't know)... Well, however, I fall in other error after adding (truly this time) -m32... But i'll see this later (must go now) and will be back to tell you.

Thanks for your eye, Tim

--
EDIT : it sounds like all the errors I've seen until now are because of a lack of "-m32" option. What is weird is that even if I add this option in the compiler and linker fields at project level, some targets seem to ignore it (and, then, I have to explicitely add the option at target level too... So, a lot of repetitive manipulations in perspective)... To be continued...

--
EDIT#2 : but, I think (sometimes), what a silly boy : creating a duplicated GCC entry at C::B level I can directly add the option at C::B level... Can't try just now, but will try this way...

--
EDIT#3 : done ! It compiles ;D

Code

||=== Build finished: 0 error(s), 232 warning(s) (8 minute(s), 56 second(s)) ===|

Title: Re: Building C::B with MinGW64
Post by: eranon on August 21, 2013, 03:36:05 am

OK, I've successfully built the contrib-plugins workspace too (unless Autoversioning which shown an error and Nassi Shneiderman which needed Boost), then ran update.bat. And now I face a new situation : when I launch this freshly built C::B (the one under output subdir) I have a long yellow warning message at right side telling me a lot of plugins are disabled because of a difference of SDK... So, what's wrong ? What should I do ?

Title: Re: Building C::B with MinGW64
Post by: stahta01 on August 21, 2013, 03:53:29 am

Quote from: eranon on August 21, 2013, 03:36:05 am

OK, I've successfully built the contrib-plugins workspace too (unless Autoversioning which shown an error and Nassi Shneiderman which needed Boost), then ran update.bat. And now I face a new situation : when I launch this freshly built C::B (the one under output subdir) I have a long yellow warning message at right side telling me a lot of plugins are disabled because of a difference of SDK... So, what's wrong ? What should I do ?

I would first try rebuilding just the SDK in the main CB Project; then ran update.bat, again.

Then, make a list of the plugins that you have bad error reporting in the main CB Project.

Rebuild just one of those plugins to see if the problem goes away. Remember to ran update.bat, again; before testing.

If you have no plugins in the main CB Project; make a list of the ones not working in contrib workspace.

I suggest skipping the wxSmith ones because they take a very long time to re-build.

Rebuild just one of those plugins to see if the problem goes away. Remember to ran update.bat, again; before testing.

Edit: If the problem does NOT go away, it is likely a PCH issues; so, deleted the precompiled header files.

PCH Files (I did not check these paths).

.objs\include\sdk_precomp.h.gch
.objs\include\sdk.h.gch

Tim S.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 21, 2013, 05:37:42 am

Thanks for you support, Tim. Well, since I did a lot of tests, I've rather deleted my working copy then checked-out the SVN trunk again. Then, I followed the sequence : built (with -m32 option and -O2 in cb_release_type) all the workspace (unless Autoversioning and Nassi S.), ran update.bat, copied the wx28_custom DLL in the output directory, then launched this fresh C::B... And bang ! No luck, I fall in error "The application was unable to start correctly (0xc000007b)".

Title: Re: Building C::B with MinGW64
Post by: stahta01 on August 21, 2013, 06:17:45 am

Did you copy the mingw dll from the MinGW compiler bin folder?
Did you compile wxWidgets and CB with the exact same MinGW compiler?
Did you remember to compile wxWidgets with the 32 bit option?

Tim S.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 21, 2013, 09:29:38 am

Quote from: stahta01 on August 21, 2013, 06:17:45 am

Did you copy the mingw dll from the MinGW compiler bin folder?

I've copied the one shipped with the C::B nightly build since there's not any mingwm10.dll in my installed tdm64-gcc-4.7.1-3 tree.

Quote from: stahta01 on August 21, 2013, 06:17:45 am

Did you compile wxWidgets and CB with the exact same MinGW compiler?

No, I can't ! Never found a way to build wxWidgets 2.8.12 DLL with TDM64-GCC (aka MinGW64) and knowing my project are against wxWidgets 2.9.5 I didn't digged. So, the wxmsw28u_gcc_custom.dll comes from a build done with TDM-GCC (aka MinGW32) under Windows 7 32-bit.

Quote from: stahta01 on August 21, 2013, 06:17:45 am

Did you remember to compile wxWidgets with the 32 bit option?

Yep, I've added -m32 at global level, directly in the compiler/linker settings.

Well, at this time (unless trying with cb_x86_wx29 or waiting for cb_x64, but I'll have less of time next days), maybe I should try to install a MingGW32 beside my MinGW64. And awaiting a solution I'll continue to build under a Win 7 32-bit with MinGW32 in a VirtualBox (a little bit slow - because of restricted resource under VirtualBox and necessity to copy the result toward my Windows 64-bit host afterward -, but it works)

Title: Re: Building C::B with MinGW64
Post by: stahta01 on August 21, 2013, 10:25:23 am

Quote from: eranon on August 21, 2013, 09:29:38 am

Quote from: stahta01 on August 21, 2013, 06:17:45 am
Did you copy the mingw dll from the MinGW compiler bin folder?

I've copied the one shipped with the C::B nightly build since there's not any mingwm10.dll in my installed tdm64-gcc-4.7.1-3 tree.

Quote from: stahta01 on August 21, 2013, 06:17:45 am
Did you compile wxWidgets and CB with the exact same MinGW compiler?

No, I can't ! Never found a way to build wxWidgets 2.8.12 DLL with TDM64-GCC (aka MinGW64) and knowing my project are against wxWidgets 2.9.5 I didn't digged. So, the wxmsw28u_gcc_custom.dll comes from a build done with TDM-GCC (aka MinGW32) under Windows 7 32-bit.

Quote from: stahta01 on August 21, 2013, 06:17:45 am
Did you remember to compile wxWidgets with the 32 bit option?

Yep, I've added -m32 at global level, directly in the compiler/linker settings.

Well, at this time (unless trying with cb_x86_wx29 or waiting for cb_x64, but I'll have less of time next days), maybe I should try to install a MingGW32 beside my MinGW64. And awaiting a solution I'll continue to build under a Win 7 32-bit with MinGW32 in a VirtualBox (a little bit slow - because of restricted resource under VirtualBox and necessity to copy the result toward my Windows 64-bit host afterward -, but it works)

So, it had no chance of working.

Tim S.

Title: Re: Building C::B with MinGW64
Post by: eranon on August 21, 2013, 10:08:58 pm

About C::B SVN 32-bit against wxWidgets 2.8.12 DLL 32-bit using TDM64-GCC for both, yes, I'm convinced too it will not have chance to be achieved... Unless someone succeeded and report his experience here ^o^

Well, at this time, I live with what I have (C::B SVN 32-bit against wxWidgets 2.8.12 DLL 32-bit using TDM-GCC) and hope a day I'll succeed with C::B SVN 64-bit against wxWidgets 2.9.5 64-bit using TDM64-GCC).

--
EDIT : just to be sure, I've nevertheless tried to rebuild wxWidgets 2.8.12 DLL 32-bit with TDM64-GCC (since my last attempt was far away in the past)... And it's like I remembered : no success ! At final step, I get this error message :

Code

i386:x86-64 architecture of input file `gcc_mswudll\monodll_version_rc.o' is incompatible with i386 output

So, it talk about winres (the resource compiler) and I already dealed with this, providing the equivalent of "-m32" option for it which is "-F pe-i386"... But it doesn't change anything : same error at the end.

Searching quickly, I've found this page where someone called billyonthemountain experienced the same situation (building wxWidgets in a side and C::B in another, for both cases), but lacking to pass "RCFLAGS="-F pe-i386" : http://forums.codeblocks.org/index.php?action=printpage;topic=12701.0 ; in his case, he solved it adding these RCFLAGS that I already provide in my case. Then, it doesn't help me.

If someone has an idea, it's welcome (and even if it's indirectly C::B related ; I'll open a thread in wx forum, when I'll have time...)

To finish, here is my full command line (here in two line to be more easily readable in the forum, but it's one line only) :

Code

mingw32-make -j 12 -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CFLAGS="-m32 -O2" CXXFLAGS="-m32 -O2" 
CPP="gcc -E -DWX_CPU_X86" LDFLAGS="-m32" RCFLAGS="-F pe-i386 -DWX_CPU_X86"

Title: Re: Building C::B with MinGW64
Post by: eranon on August 23, 2013, 12:28:17 am

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

Title: Re: Building C::B with MinGW64
Post by: eranon on August 23, 2013, 01:43:12 am

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"

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

Title: Re: Building C::B with MinGW64
Post by: Huki on September 15, 2013, 11:51:26 pm

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 (http://sourceforge.net/projects/mingwbuilds/) (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

Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: daniloz on February 28, 2011, 08:54:18 pm