PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Do you have a question about makefiles, a compiler or IDE you are using and need to know how to set it up for wxWidgets or why it doesn't compile but other IDE's do ? Post your questions here.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

I am aware that there already are several recent guides to using wxWidgets with MinGW and Code::Blocks. However, I wrote most of mine almost two years ago, but did not find time to finish it. But now I did and updated it for the latest versions of wxWidgets, MinGW and Code::Blocks.

My guide hopes to assist the readers with decisions regarding which wxWidgets version and configuration to use and show how to build wxWidgets using MinGW with various parameters affecting the resulting build. It also describes in detail setting-up a wxWidgets project in popular IDE Code::Blocks. Its page count may seem off-putting to some, but there is not that much text, there are many pictures and I was generous with whitespace.

I wrote the guide in Microsoft Word, using complex formatting and it seems that converting all of it to MediaWiki or HTML format is quite difficult, so at least for the time being, it is provided only in the PDF format.

The guide is available at https://github.com/PBfordev/wxpbguide as wxPBGuide.pdf. I recommend using a decent PDF viewer instead of GitHub's built-in one, which lacks useful features such as displaying a navigable TOC or clicking on document's internal cross links.

Perhaps the guide helps someone, it should cover all necessary information, hopefully presented in a simple and understandable way.

Versions of software used in guide
wxWidgets: 3.2 (3.2.2.1 at the time of writing)
MinGW: MSYS2 mingw-w64-ucrt-x86_64-toolchain (GCC 13.2 at the time of writing)
Code::Blocks: 20.03

Table of Contents
----------
1 Introduction
2 Basic wxWidgets Information
2.1 wxWidgets Versions
2.2 Shared vs Static Linking
2.3 Multilib vs Monolithic Build
2.4 Debug and Release Configuration
2.5 32-bit vs 64-bit Build
2.6 To Build or Not to Build
3 Building wxWidgets with MinGW
3.1 Choosing MinGW Distribution
3.2 Installing MSYS2
3.3 Installing MSYS2 packages for developing C++ applications
3.4 Downloading wxWidgets Sources
3.5 Adding System Environment Variable WXWIN
3.6 The Build
3.6.1 Starting Simple
3.6.2 Improving Build Commands
3.6.3 Making wxWidgets Build Faster
3.6.4 Viewing Build Results
3.6.5 Using the Minimal Sample to Test the Build
3.6.6 Cleaning the Build
3.6.7 Building wxWidgets Statically
3.6.8 More Build Options
4 Setting Up wxWidgets Project with Code::Blocks and MinGW
4.1 Installing Code::Blocks
4.2 Configuring the Debugger
4.3 Configuring the Compiler
4.4 Creating Global Variable wx
4.5 Creating a wxWidgets Project with Project Wizard
4.5.1 Selecting wxWidgets Project Template
4.5.2 Wizard Page 1: Welcome
4.5.3 Wizard Page 2: wxWidgets Version
4.5.4 Wizard Page 3: Project Title and Paths
4.5.5 Wizard Page 4: Project Author
4.5.6 Wizard Page 5: GUI Builder and Application Type
4.5.7 Wizard Page 6: wxWidgets Location
4.5.8 Wizard Page 7: Compiler and Debug/Release Configurations
4.5.9 Wizard Page 8: Various Configuration Options
4.5.10 Wizard Page 9: Advanced Options
4.5.11 Wizard Page 10: Additional Libraries
4.6 Adjusting Project Settings
4.6.1 Setting C++ Standard Used in the Project
4.6.2 Setting Preprocessor Define NDEBUG for the Release Build Target
4.6.3 Marking the Application DPI-Aware
4.7 Finally Finished!
4.8 Extra Reading: wxWidgets Code::Blocks Project Under the Hood
4.8.1 Compiler Include Folders
4.8.2 Preprocessor Defines
4.8.3 Linker Settings
4.8.4 Using Static Instead of Shared wxWidgets Build
Last edited by PB on Mon Aug 21, 2023 9:34 am, edited 9 times in total.
tuk1
Earned some good credits
Earned some good credits
Posts: 114
Joined: Sun Oct 08, 2017 9:36 am

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by tuk1 »

Not sure if youre inviting replies here and couldnt find a way to pm.

Using wx 3.1.4 and gcc 10.2.0
All went ok until the build step, tried the commands for dynamic and static, but both failed at the end:
C:\Users\TP1\Desktop\CODE BLOCKS\wxWidgets-3.1.4\build\msw>IF %ERRORLEVEL% NEQ 0 goto FAIL

C:\Users\TP1\Desktop\CODE BLOCKS\wxWidgets-3.1.4\build\msw>goto SUCCESS

C:\Users\TP1\Desktop\CODE BLOCKS\wxWidgets-3.1.4\build\msw>:FAIL
C:\Users\TP1\Desktop\CODE BLOCKS\wxWidgets-3.1.4\build\msw>echo Build failed!
Build failed!

C:\Users\TP1\Desktop\CODE BLOCKS\wxWidgets-3.1.4\build\msw>pause
Press any key to continue . . .
set PATH=c:\msys64\mingw32\bin;%PATH%
cd /d %WXWIN%\build\MSW
REM Build wxWidgets Shared Debug configuration with C++17 support
mingw32-make -f makefile.gcc SHARED=1 BUILD=debug CXXFLAGS="-std=c++17"
IF %ERRORLEVEL% NEQ 0 goto FAIL
REM Build wxWidgets Shared Release configuration with C++17 support
mingw32-make -f makefile.gcc SHARED=1 BUILD=release CXXFLAGS="-std=c++17"
IF %ERRORLEVEL% NEQ 0 goto FAIL
goto SUCCESS
:FAIL
echo Build failed!
pause
goto FINISHED
:SUCCESS
:FINISHED
and..
set PATH=c:\msys64\mingw32\bin;%PATH%
cd /d %WXWIN%\build\MSW
REM Build wxWidgets Static Debug configuration with C++17 support and GCC libraries linked statically
mingw32-make -f makefile.gcc SHARED=0 BUILD=debug CXXFLAGS="-std=c++17" LDFLAGS="-static"
IF %ERRORLEVEL% NEQ 0 goto FAIL
REM Build wxWidgets Static Release configuration with C++17 support and GCC libraries linked statically
mingw32-make -f makefile.gcc SHARED=0 BUILD=release CXXFLAGS="-std=c++17" LDFLAGS="-static"
IF %ERRORLEVEL% NEQ 0 goto FAIL
goto SUCCESS
:FAIL
echo Build failed!
pause
goto FINISHED
:SUCCESS
:FINISHED
How to troubleshoot?
wxWidgets(v3.2.2.1) - Vs2022(v143) - Win10(x64) - DialogBlocks(v5.16.5_Unicode)
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

Did you run those commands as a batch file as stated in the guide, which are also available here?

You should see the actual build output above the "Press any key to continue . . ." line

BTW, if you have CPU with at least 4 cores and an SSD, I strongly suggest you use the "parallel" versions of the bat files, they are much faster.
tuk1
Earned some good credits
Earned some good credits
Posts: 114
Joined: Sun Oct 08, 2017 9:36 am

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by tuk1 »

The batch file did the trick. I guess it didnt like the commands being block pasted into cmd.

One last thing, when I tried to run the project at the end, I got some errors:
||=== Build: Debug in Test (compiler: msys2-mingw-w64-i686) ===|
\Program Files\CodeBlocks\MinGW\lib\liboleacc.a||No such file or directory|
\Program Files\CodeBlocks\MinGW\lib\libuxtheme.a||No such file or directory|
||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 4 second(s)) ===|
I was able to resolve by copying over the 2 missing files as per the OP on this thread:
viewtopic.php?f=19&t=47061

The folders didnt exist("\MinGW\lib\"), I had to create those first before adding the missing files ...any ideas as to the cause, maybe a misstep?
wxWidgets(v3.2.2.1) - Vs2022(v143) - Win10(x64) - DialogBlocks(v5.16.5_Unicode)
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

No such copying should be ever needed.

The build log indicates that C::B looks for the libraries in its bundled compiler folder instead of the MSYS folder?

You either did not follow my guide or you set something in the global C::B settings that messes with the specific compiler / project settings.
PaulUK
Knows some wx things
Knows some wx things
Posts: 43
Joined: Wed Nov 18, 2020 12:55 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PaulUK »

PB, thank you very much for writing the guide. It helped me install wxWidgets with CodeBlocks. Something I would like to do is to have the option of shared or monolithic libraries, both in 32 and 64 bit, as my aim is to write software that will use a lot of memory and perhaps large files so I want the option of 64 bit. Is there a sensible or convenient way to build wxWidgets such that I can easily choose which library to use from within CodeBlocks, so that there's no confusion as to where the builds are saved or which compiler to choose from CodeBlocks? I think it may get messy if there is no order to how this is done. Thank you.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

PaulUK,

firstly, if you think that for your software 32-bit address space would not be enough, I think it makes little sense to provide also 32-bit version; however, I think doing it should be both doable and simple (provided that all libraries you need are available in 32-bit).

(chapter numbers are based on v3.0 of the guide)

Secondly, I am not sure if it was a typo or not. It is not "shared or monolithic", these two are not mutually exclusive. It is static vs shared (DLL), when in the former the libraries are linked statically while in the latter dynamically (where the DLLs are needed), see chapter 2.2. It is also multilib vs monolithic, where in the former many libraries are produced while in the latter only few are, see chapter 2.3.

You can have both 32- and 64-bit wxWidgets (as well as shared and static, and multilib and monolithic) builds happily coexisting. To do that I would make sure that:

1. You install both 32- (msys2-mingw-w64-i686) and 64-bit (msys2-mingw-w64-x86_64) compiler toolchains while not adding either to the PATH. You will also add those two compilers to Code::Blocks. While my guide describes using only one toolchain, you will just do what is described for the 32-bit one and then repeat for the 64-bit one with necessary changes, see chapter 3.3.

2. You build wxWidgets in both 32- and 64-bit configurations. 32-bit shared build is generally produced in WXDIR/lib/gcc_dll and 64-bit one in WXDIR/lib/gcc_x64_dll. However, C::B wizard does not support custom compiler prefix (gcc_x64 here) so you need to use CFG parameter instead and the 64-bit shared build will be placed in WXDIR/lib/gcc_dll_x64. If you do not need the wizard you can use compiler prefix (COMPILER_PREFIX=gcc_x64).

So, the simplifed batch file for building 32-bit shared debug build would look like this
set PATH=C:\msys64\mingw32\bin;%PATH%

cd /d %WXWIN%\build\MSW

mingw32-make -f makefile.gcc SHARED=1 SHELL=cmd.exe
While the one for 64-bit like this (differences to 32-bit build in red)
set PATH=C:\msys64\mingw64\bin;%PATH%

cd /d %WXWIN%\build\MSW

mingw32-make -f makefile.gcc SHARED=1 CFG=_x64 SHELL=cmd.exe
Obviously, the real batch file would look like build-library-shared-parallel.bat where for the 64-bit build you would make the changes above, i.e., change the path for mingw and add CFG=_x64 to every line starting with mingw32-make, before SHELL=cmd.exe

3. For the 64-bit wxWidgets build built as described above, in the C::B project wizard, you need to set "Configuration" to _x64 (see chapter 4.5.9).

My guide does not describe the monolithic build. However, the only real difference to the multilib build would be adding MONOLITHIC=1 to the make parameters when building wxWidgets (chapter 3.6.1) and then in C::B wizard checking "wxWidgets DLL is built as a monolithic library" (chapter 4.5.9).

If you want to have both multilib and monolithic builds, you need to make sure they are not produced in the same folder, so perhaps for the 32-bit monolithic build CFG would be _mono while for the 64-bit _mono_x64, resulting in folder names with monolithic shared builds WXDIR/lib/gcc_dll_mono and WXDIR/lib/gcc_dll_mono_x64. FWIW, I would decide whether I want multilib or monolithic build and stick to that one, instead of having built both.

EDIT
Sorry, I did not realize you probably want both 32- and 64-bit build targets in the same C::B project. C::B wxWidgets wizard does not allow this but it is simple enough to do by hand.
1. Create the project for the 32-bit build as described in chapter 4.5 of my guide.
2. Use menu command Project/Properties and in the dialog go to the "Build targets" tab. There select the "Debug" target in the targets list, click "Duplicate" and change the name of the new target to "Debug_x64". Select target "Debug_x64" and in "Output filename" and "Objects output dir" change "Debug" to "Debug_x64", e.g., "Objects output dir" will be "obj\Debug_x64\" instead of "obj\Debug\". You can also change the file name so you easily differentiate between 32- and 64-bit executables if you allow the user installing them in the same folder.
3. Repeat the same you did in #2 but for the "Release" target.
4. Use menu command Project/Build options and in the dialog for the target "Debug_x64" change (a) selected compiler to "msys2-mingw-w64-x86_64" and (b) in all three tabs on the tab "Search directories" wherever there is "gcc_dll", change it to "gcc_dll_x64" (e.g., in "Compiler" there will be "$(#wx)\lib\gcc_dll_x64\mswud" instead of "$(#wx)\lib\gcc_dll\mswud"). Press "OK" to confirm the changes.
5. Repeat the same you did in #4 but for the "Release_x64" target.
Last edited by PB on Tue May 11, 2021 6:58 pm, edited 9 times in total.
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7449
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by ONEEYEMAN »

Hi,
I would like to alsoi point out that unless you plan to work on CodeBlocks itself you don't need a monolithic build.
It is very rarely tested by core wx-devs and can and will easily give problems to the user code.

Also, unless you yourself plan to produce the dynamically link library(-ies), you better create a static build of wxWidgets whcih will produce a one executab;le that will be distributed.
You will not care much about where to place all those DLLs. But this paragraph applies for Windows only. For *nix/Mac the usual approach is to create a dynamic build and let the dynamic linker resolve all the dependencies.

Thank you.
ollydbg23
Super wx Problem Solver
Super wx Problem Solver
Posts: 438
Joined: Fri Dec 12, 2008 10:31 am

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by ollydbg23 »

Some information maybe useful for the tutorial.

The msys2 now have wxWidgets 3.1.5 version https://packages.msys2.org/base/mingw-w64-wxWidgets3.1 and 3.0.5 version https://packages.msys2.org/base/mingw-w64-wxWidgets.

To use those libraries under codeblocks, I use such way: https://forums.codeblocks.org/index.php ... #msg161585

The most interesting is the variable

Code: Select all

TARGET_COMPILER_DIR
and all the header files are in it's sub-folders.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

ollydbg23 wrote: Thu May 13, 2021 10:25 am The msys2 now have wxWidgets 3.1.5 version
I noticed that there seems to be also a static version? How do you differentiate between the static and shared wxWidgets build in the C::B wxWidgets project wizard*? How is it with the debug build of wxWidgets libraries, i.e., those built without NDEBUG define so the asserts show there but not in the version distributed to the user (built with NDEBUG defined)?

AFAICT, that package also does not include the shiny new wxWebView Edge backend, but I guess it is not important for many users and I also understand why it may not be included.

* I have a lot to say and do about that wizard but I will post that on C::B forum as soon as I can.
ollydbg23
Super wx Problem Solver
Super wx Problem Solver
Posts: 438
Joined: Fri Dec 12, 2008 10:31 am

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by ollydbg23 »

PB wrote: Thu May 13, 2021 11:11 am
ollydbg23 wrote: Thu May 13, 2021 10:25 am The msys2 now have wxWidgets 3.1.5 version
I noticed that there seems to be also a static version?
If you look at its file list: https://packages.msys2.org/package/ming ... po=mingw64
I see that it has both .a file and .dll.a file, I think the first is static libs and the second is dynamic libs.


How do you differentiate between the static and shared wxWidgets build in the C::B wxWidgets project wizard*?
C::B's wizard is broken for using the msys2 prebuild wx libraries, I just simply create a console application, and later add the include and lib paths and options, and this is not hard to do. After that, I can copy and paste the .cbp file everywhere. :D

How is it with the debug build of wxWidgets libraries, i.e., those built without NDEBUG define so the asserts show there but not in the version distributed to the user (built with NDEBUG defined)?
I don't know, maybe it should be configured by build script(see: https://github.com/msys2/MINGW-packages ... Widgets3.1 )
AFAICT, that package also does not include the shiny new wxWebView Edge backend, but I guess it is not important for many users and I also understand why it may not be included.
Yes, as far as I know, it is IE based, not Edge based. I don't care at least right now. :D
* I have a lot to say and do about that wizard but I will post that on C::B forum as soon as I can.
OK, thanks, the wx wizard of C::B is normally check if a header file exits...
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

ollydbg23 wrote: Thu May 13, 2021 2:23 pm
AFAICT, that package also does not include the shiny new wxWebView Edge backend, but I guess it is not important for many users and I also understand why it may not be included.
Yes, as far as I know, it is IE based, not Edge based. I don't care at least right now. :D
I mean I thought that the reason why the new Edge backend is not enabled is because it needs 3rd party files (WebView2 SDK) to build.
PaulUK
Knows some wx things
Knows some wx things
Posts: 43
Joined: Wed Nov 18, 2020 12:55 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PaulUK »

Thank you all for your helpful advise and clarifying matters regarding the various types of build. It's much appreciated.
FrankR
Earned a small fee
Earned a small fee
Posts: 21
Joined: Fri Dec 02, 2022 9:58 am

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by FrankR »

Many thanks for this fantastic and very helpful work. First time I got wxWidgets with C::B and the newest MinGW runing.

There's only one issue. Regarding the test.cpp example (as well as wxWidgets Hello World example) I get some depracated warnings within wxWidgets' own header files (i downloaded release 3.2.1!). Here come two examples:

Code: Select all

c:\SDKs\wxWidgets-3.2.1\include\wx\timer.h|182|warning: 'wxTimerEvent::wxTimerEvent()' is deprecated: wxTimerEvent not supposed to be created by user code [-Wdeprecated-declarations]
c:\SDKs\wxWidgets-3.2.1\include\wx\msw\font.h|139|warning: 'wxFont::wxFont(int, int, int, int, bool, const wxString&, wxFontEncoding)' is deprecated: use wxFONT{FAMILY,STYLE,WEIGHT}_XXX constants ie: wxFONTFAMILY_SWISS, wxFONTSTYLE_NORMAL, wxFONTWEIGHT_BOLD [-Wdeprecated-declarations]|
How can there be depracated things in a version marked as release and how can i stop these warnings?
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: PB’s Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks

Post by PB »

FrankR wrote: Sun Dec 04, 2022 9:23 am How can there be depracated things in a version marked as release and how can i stop these warnings?
Firstly, this has nothing to do with my guide. Please do not post such questions in the Guide thread, start a new topic in the appropriate forum section.

Secondly, deprecation has nothing to do with release or debug build but the wxWidgets version. I am also quite sure it is not wxWidgets "own" issue but the user code issue. If you did not write the code, perhaps you are using a rather outdated (the two methods you posted were deprecated many years ago) tool doing that.

The correct solution is to stop using deprecated API. The quicker solution may be to build wxWidgets with WXWIN_COMPATIBILITY_x_y setting see Backward Compatibility Overview, but that will stop working in the next wxWidgets version; moreover, there is a reason why the API was deprecated.
Post Reply