Compiling wxWidgets 2.8.12 with MinGW-Builds 5.2.0 for use in CodeBlocks Windows

[headkase]

MinGW-Builds can be found: Here in either "Toolchains targetting Win32/64" and then "Personal Builds" and "mingw-builds" then 5.2.0 and then your threading and exception preferences.

To build Code::Blocks from SVN, you generally follow the instructions: Here.

The problem is that with MinGW-Builds 5.2.0 the compilation will fail while building wxWidgets 2.8.12.  Just fail.  Goodbye, try again.

I have been dealing with this issue, and as a result have had to use the provided nightlies for quite the while, but now after much persistence I have found the solution.

See: Here.

In the file: \path\to\mingw32\i686-w64-mingw32\include\commctrl.h

(Or 64 bit 5.2.0: \path\to\mingw64\x86_64-w64-mingw32\include\commctrl.h)

Find the _WIN32_IE 0x0501 definition block and make it look exactly like this:

Code Select Expand

ifndef WINRESRC
ifndef _WIN32_IE
//#define _WIN32_IE 0x0501
endif
endif
#define _WIN32_IE 0x0603

Now, wxWidgets on MinGW-Builds 5.2.0 will compile and then you can move onto compiling Code::Blocks itself.  And there was much rejoicing. 

You can even build wxWidgets in 64 bit (using "CFG=64" on its build line) MinGW 5.2.0 BUT there is no 64 bit vanilla project in the Code::Blocks source to go from there.

I used these exact lines in config.gcc for wxWidgets:

Code Select Expand

# Standard flags for CC
CFLAGS ?= -fno-keep-inline-dllexport

# Standard flags for C++
CXXFLAGS ?= -fno-keep-inline-dllexport -std=gnu++11 -fpermissive

I'm pretty happy now, the only thing that could make things even better is if a 64 bit codeblocks.cbp project was added to the trunk source so I could go full 64 bit with everything. 

[MortenMacFly]

Code Select Expand

# Standard flags for CC
CFLAGS ?= -fno-keep-inline-dllexport

# Standard flags for C++
CXXFLAGS ?= -fno-keep-inline-dllexport -std=gnu++11 -fpermissive

Why don't you expand this to:

Code Select Expand

# Standard flags for CC
CFLAGS ?= -D_WIN32_IE=0x0603 -fno-keep-inline-dllexport

# Standard flags for C++
CXXFLAGS ?= -D_WIN32_IE=0x0603 -fno-keep-inline-dllexport -std=gnu++11 -fpermissive
?

This would avoid to patch the source files.

[headkase]

I didn't do it simply because of ignorance that it could be done.  Thank you for the tip, I'm going to go do a test compile right now.

[headkase]

Built successfully, thank you again.  I bumped -std=gnu++11 up to -std=gnu++14 too with no adverse affects.  May not even need that but I'm not concerned over it.

May I ask however is that is there a simple method to modify the codeblocks.cbp and contributor's plugin workspace to target 64 bit?  Compilation fails with the regular workspace when using a 64 bit compiler toolchain.  Also, right now the only 64 bit projects use wx 3.0.x and that version of wx while I can compile it fine just doesn't work for me.  The cursor caret in an editor window with it does not behave properly.

[MortenMacFly]

May I ask however is that is there a simple method to modify the codeblocks.cbp and contributor's plugin workspace to target 64 bit?

Whats wrong with the 64 bit workspace (CodeBlocks_wx30_64.cbp) ?

[oBFusCATed]

What do you mean by 'does not behave properly'?
If there is bug in these kind of builds, we need to fix them. So please report!

[headkase]

What happens on my system, I can compile wxWidgets 3.0.2 64 bit with no errors.  Then I can build codeblocks wx 30 64 also with no errors.  Run it, it loads fine.  However, open a text window the cursor caret does not behave properly.  If you go up or down a line it may leave an old cursor bar graphic there, or up or down, left or right, all the arrow keys: it either leaves a artifact or does not update.  Either graphical garbage or an invisible caret.  No errors are thrown at all that I am aware of.  It just doesn't work like it's supposed to.

I am not a technical expert so I do not know where to begin troubleshooting that.  If you provide a concrete list of steps to try and report the results of then I would gladly do them.

[oBFusCATed]

Can you build the stc sample in the <wxroot>/samples/stc and try if it behaves the same?

[headkase]

Found the root cause and some issues in the latest SVN.

First of all, SVN 10625 errors when compiling with wx 3.0.2:

http://i.imgur.com/yexc1qM.jpg

Going back to SVN 10623 compiling with wx 3.0.2 succeeds.

Now, I found the fix for the issue.  wxWidgets 3.0.2 has to be build with the CFG=64 option:

Code Select Expand

mingw32-make -f makefile.gcc CFG=64 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1

Also, in config.gcc I did no keep inline and -std=gnu++11

And then the codeblocks wx 3.0.x 64 bit project -> build options -> custom variables, WX_CFG has to be given to value "64"

Then the project will compile fine and most importantly, the cursor caret in the editor window now works correctly.

[headkase]

Arg, no dammit, still issues.  Now the cursor works fine until you scroll within source code.  I don't have enough time to build the sample to test that out before I head off to work.  Tomorrow after work I'll have time to try that then.

[headkase]

Can you build the stc sample in the <wxroot>/samples/stc and try if it behaves the same?

Ok, it wasn't as involved as I thought it would be to compile that test program.  With CFG=64, and the exact same compilation of the library that does not work correctly in Code::Blocks -> the stc sample works completely correct.  I scrolled around, added and removed characters, everything - it works fine.

[oBFusCATed]

Unpleasant.

[headkase]

Subsequent posts from this thread were split into: This thread.