Compiling wxWidgets with MinGW
|This article applies to the following versions|
|Status: Up to Date|
|Using Makefiles to compile wxWidgets|
Please follow the steps described in Installing MinGW under Windows.
PLEASE NOTE: There is an issue which rapidly becomes apparent down below. Make sure your path contain neither the MSYS nor CYGWIN directories or sub-directories. The utility mingw32-make seems to have issues with programs in these directories. If these directories are referenced, remove them from the path. Otherwise you may lose fist-fulls of hair. This problem is discussed in the troubleshooting notes, below.
Download and Install wxWidgets
Build the library
Open the command prompt (Start > Run... > cmd). Change the directory to the build\msw folder. For example:
Clean up the source:
mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release clean
Then, compile the library:
mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release
You can add the -j parameter to use parallel builds, e.g. -j4 to use 4 cores
|Note: For more information on the UNICODE and BUILD options, see WxWidgets Build Configurations.|
Under some circumstances, while compiling on multiple cores, you may receive compilation error at the very beginning about missing setup.h file. To overcome this issue, generate this file first with setup_h tag at the end of build parameters:
mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release setup_h
In the example above a DLL was created under \lib\gcc_dll. The resultant setup.h file can be found under \lib\gcc_dll\mswu\wx
Build the static library (on Windows)
If you cannot build wxWidgets static library, try the following commands (specify SHELL=CMD.exe, otherwise mingw32-make (GNU make) will use sh.exe as SHELL by default):
a. Build UNICODE version, static library:
mingw32-make SHELL=CMD.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=0
b. Build UNICODE version, MONOLITHIC static library:
mingw32-make SHELL=CMD.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=0 MONOLITHIC=1
Specify -j4 option to build wxWidgets library using 4 parallel jobs (if your CPU has 4 threads/cores). It will increase your building speed by ~4 times.
When using TDM-GCC to compile wxWidgets (3.x). If the above command doesn't work then please try the following command:
mingw32-make SHELL=CMD.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=0 MONOLITHIC=1 CXXFLAGS="-fno-keep-inline-dllexport -std=gnu++11"
CreateProcess, The system cannot find the file specified.
if you get errors like this:
if not exist gcc_mswu mkdir gcc_mswu process_begin: CreateProcess(NULL, -c "if not exist gcc_mswu mkdir gcc_mswu", ...) failed. make (e=2): The system cannot find the file specified. mingw32-make: [gcc_mswu] Error 2 (ignored) if not exist ..\..\lib\gcc_lib mkdir ..\..\lib\gcc_lib process_begin: CreateProcess(NULL, -c "if not exist ..\..\lib\gcc_lib mkdir ..\..\lib\gcc_lib", ...) failed. make (e=2): The system cannot find the file specified. mingw32-make: *** [..\..\lib\gcc_lib] Error 2
It's probably because you have MSYS (or CYGWIN (or both)) installed and the MSYS\bin and/or cygwin\bin folder(s) are in your PATH, and this confuses mingw32-make. Remove these folders from your PATH and try again, it should work. (Alternatively, use MSYS to build wxWidgets, as described in build\msw\install.txt in the wxWidgets source tree).
Note: MSYS\bin turns in to /bin, if you look from MinGW shell.
If you don`t have MSYS, edit your PATH environment variable and make sure your PATH points to the bin directory of your mingw installation.
Alternative: mingw32-make -f makefile.gcc SHELL=CMD .... (but give me command line too long at linking.)
Alternative 2: Per this stack overflow question, adding
<MinGW install directory>\libexec\gcc\mingw32\<GCC version>
to the PATH environment variable solves this issue. An example is shown below:
Keep in mind that environment variable changes don't reflect on current terminals. You need to close your current build terminal and open a new one to see the updated PATH.
To fix issues when compiling static library with MONOLITHIC option
Apparently there is a bug in mingw32-make with very long command lines which makes it (sometimes?) eat characters in them. This problem shows up with "No such file or directory" referencing a garbled filename, e.g. "ar: gcc_mswu\moolib_fontmap.o: No such file or directory"
Please modify makefile.gcc as following:
ifeq ($(MONOLITHIC),1) ifeq ($(SHARED),0) $(LIBDIRNAME)\libwx$(PORTNAME)$(WXUNIVNAME)$(WX_RELEASE_NODOT)$(WXUNICODEFLAG)$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR).a: $(MONOLIB_OBJECTS) if exist [email protected] del [email protected] ar rcu [email protected] $(MONOLIB_OBJECTS) ranlib [email protected] endif endif
Replace second occurrence of $(MONOLIB_OBJECTS) with gcc_mswu\monolib*.o:
ifeq ($(MONOLITHIC),1) ifeq ($(SHARED),0) $(LIBDIRNAME)\libwx$(PORTNAME)$(WXUNIVNAME)$(WX_RELEASE_NODOT)$(WXUNICODEFLAG)$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR).a: $(MONOLIB_OBJECTS) if exist [email protected] del [email protected] ar rcu [email protected] gcc_mswu\\monolib*.o ranlib [email protected] endif endif
ar: gcc_mswu\monolib_dragigg.o: No such file or directory
If the build fails like so:
if exist ..\..\lib\gcc_lib\libwxmsw28u.a del ..\..\lib\gcc_lib\libwxmsw28u.a ar rcu ..\..\lib\gcc_lib\libwxmsw28u.a gcc_mswu\monolib_dummy.o gcc_mswu\monolib_appbase.o gcc_mswu\monolib_arcall.o [More .o files] ar: gcc_mswu\monolib_dragigg.o: No such file or directory makefile.gcc:4018: recipe for target '..\..\lib\gcc_lib\libwxmsw28u.a' failed mingw32-make: *** [..\..\lib\gcc_lib\libwxmsw28u.a] Error 1
the solution for the "The input line is too long" problem seems to solve the issue.
Grepping the source tree for "monolib_dragigg" returns no results and the "ar" command itself carries no reference to "gcc_mswu\monolib_dragigg.o", so it is unclear why this issue occurs.
Memory Exhausted (bin/ld.exe: out of memory allocating N bytes)
If you get "memory exhausted" errors, this is due to a Mingw bug.
tdm-mingw tends to be less prone to this issue : http://tdm-gcc.tdragon.net/ This applies to MinGW with installers 20110316 and 20110530 at least.
|Note: Make sure to make a clean build after switching compilers. Also if you install both regular and TDM mingw check your PATH carefully to get the correct one when you build.|
It is also recommended to build non-monolithic, since monolithic builds take more RAM (debug builds especially; some people report that monolithic-debug builds require more RAM than a 32-bits system can have).
Another option is to add the following build flags :
ld returned 5 exit status
You most likely got this after experiencing the error above and switching to TDM gcc and trying the build again. This seems to be related to the leftover
remnants from your previous build. (
mingw32-make -f makefile.gcc seems insufficient to clean this).
Try building from a fresh wxWidgets source tree
While compiling your projects, you might get some "undefined reference" errors. In my case this was due to a wrong order in the g++ call : your static libs MUST be given before shared libs.
This might not work (please note the respective positions of "-lwx_mswXXXXXX" and "XXXXXXXXXXX/libXXXXXX.a") :
g++ -Wall -g -fexceptions -Wall -g -fexceptions -I/usr/local/lib/wx/include/msw-ansi-release-2.6 \ -I/usr/local/include/wx-2.6 -D__WXMSW__ -DWXUSINGDLL=1 -DNO_GCC_PRAGMA -o xpe.exe -Wl,--subsystem \ -Wl,windows -mwindows xpe.o xpemw.o -L/usr/local/lib -mthreads -lwx_msw_xrc-2.6 -lwx_msw_qa-2.6 \ -lwx_msw_html-2.6 -lwx_msw_adv-2.6 -lwx_msw_core-2.6 -lwx_base_xml-2.6 -lwx_base_net-2.6 \ -lwx_base-2.6 ../src/components/codeeditor/libcodeeditor.a ../src/lib/liblogging.a ../src/lib/libstring.a ../src/components/codeeditor/libcodeeditor.a(tcodeeditor.o)(.text+0x169): In function `ZN11TCodeEditorC2EP8wxWindowiRK8wxString': C:/GNU/msys/1.0/home/Administrateur/xpe_project/src/components/codeeditor/tcodeeditor.cpp:45: undefined reference to `_imp__wxDefaultSize' ../src/components/codeeditor/libcodeeditor.a(tcodeeditor.o)(.text+0x2f4): C:/GNU/msys/1.0/home/Administrateur/xpe_project/src/components/codeeditor/tcodeeditor.c pp:46: undefined reference to `_imp___ZN22wxSystemSettingsNative9GetColourE14wxS
This correction should make it working (please note the respective positions of "-lwx_mswXXXXXX" and "XXXXXXXXXXX/libXXXXXX.a"):
g++ -Wall -g -fexceptions -Wall -g -fexceptions -I/usr/local/lib/wx/include/msw-ansi-release-2.6 \ -I/usr/local/include/wx-2.6 -D__WXMSW__ -DWXUSINGDLL=1 -DNO_GCC_PRAGMA -o xpe.exe -Wl,--subsystem \ -Wl,windows -mwindows xpe.o xpemw.o ../src/components/codeeditor/libcodeeditor.a ../src/lib/liblogging.a \ ../src/lib/libstring.a -L/usr/local/lib -mthreads -lwx_msw_xrc-2.6 -lwx_msw_qa-2.6 -lwx_msw_html-2.6 \ -lwx_msw_adv-2.6 -lwx_msw_core-2.6 -lwx_base_xml-2.6 -lwx_base_net-2.6 -lwx_base-2.6
In some cases, actually everything is fine, but you might have more than one similar complier installed on your machine.
For a real example, I have C:\WinAVR-20100110\bin;C:\WinAVR-20100110\utils\bin; installed on my machine for some microcontroller firmware development.
The installed WinAVR containing a series GNU compiler like gcc, g++ , etc.
As the WinAVR tool chain is also registered to the window via PATH environment variable.So same kind of error as aboved occurs when I tried to compile wxWidgets-2.8.11.
This could be solved by temporary remove the related Winavr directory locaiton from PATH environment variable.(Not only your current user environment variable also the Global environment variable set by administrator)