Compiling wxWidgets with MinGW

Platform	wxWidgets	MinGW
This article applies to the following versions
Windows XP	2.8.11	5.1.4
Windows 7	2.9.1	5.1.4
Windows 7	3.0.0	5.1.4
Status: Up to Date

Related Articles
Using Makefiles to compile wxWidgets

Install MinGW

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

See Downloading and installing wxWidgets.

Build the library

Open the command prompt (Start > Run... > cmd). Change the directory to the build\msw folder. For example:

CD wx\\wx288\\build\\msw

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.

Build Output

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

NOTE:

Executables created with can be rather BIG. In case you compile in DEBUG mode, the files become VERY BIG (>20 MB wxWidgets Minimal sample). With strip you can reduce the size, but it will always remain bigger than executables created with Visual Studio. In addition to that, Visual Studio seems to compile faster but I am not sure about this.

Troubleshooting

Build the static library

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.

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 show below:

D:\mingw\libexec\gcc\mingw32\4.8.1

To fix the issue "The input line is too long" when compile static library with MONOLITHIC option

Please modify makefile.gcc as following:

From:

ifeq ($(MONOLITHIC),1)
ifeq ($(SHARED),0)
$(LIBDIRNAME)\libwx$(PORTNAME)$(WXUNIVNAME)$(WX_RELEASE_NODOT)$(WXUNICODEFLAG)$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR).a: $(MONOLIB_OBJECTS)
	if exist $@ del $@
	ar rcu $@ $(MONOLIB_OBJECTS)
	ranlib $@
endif
endif

Replace $(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 $@ del $@
	ar rcu $@ gcc_mswu\\monolib*.o
	ranlib $@
endif
endif

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 : CXXFLAGS="-fno-keep-inline-dllexport"

References:

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

undefined reference

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

Winavr interference

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)