Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building C::B with MinGW64
MortenMacFly:
--- Quote from: daniloz on February 28, 2011, 08:54:18 pm ---Can anyone successfully build the svn trunk version using MinGW64 on win7 ??
--- End quote ---
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).
thomas:
--- 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.
--- End quote ---
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.
eranon:
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).
--- End quote ---
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.
--- End quote ---
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]
thomas:
--- Quote from: eranon on August 20, 2013, 02:35:01 pm ---WoW64 layer (bottleneck)
--- End quote ---
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).
--- End quote ---
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.
eranon:
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))
--- End code ---
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...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version