Compiling GTK for Win3231 January 2012
This article details building GTK v2.24.x from source for Windows using MinGW/MSYS. The original motive was the lack of OpenGL support (via GtkGlExt) in the standard Windows binary 'bundle', which is further compounded by there being no official Win32 binary release of GtkGlExt. There is also the secondary motive of having an audited (i.e. tested) binary/source package pair for licencing purposes. There are quite a few HOWTOs kicking around the internet, of which the one by Fragrant Memories and a MinGW/MSYS-orientated one were the most helpful. However even with these information sources it is not a trivial task, so this article will also try to document ways the process goes wrong.
Installing MinGW/MSYSMinGW/MSYS has improved a lot since I first came across it a few years ago, and although I am not a big fan of download-on-the-fly installers, it has made installing MSYS quite easy. The important component options are
MSYS Basic System&
MinGW Developer Toolkit, although since I doubt it makes much different to overall download time you may as well simply tick all components. Once installed load up the MinGW Shell (if you did not install the Start menu short-cuts, the start-up batch file is located at
C:\MinGW\msys\1.0\msys.batby default), and run the following commands:
mingw-get install msys-wget
mingw-get install msys-unzip
Getting all the packagesYou'll need to download:
- Pkg-Config (requires Gettext 0.18.1.1 Run-time and GLib 2.28.8 run-time)
- Z-Lib 1.2.5 run-time and headers
- libPNG 1.4.8, libJPEG v8b, and libTIFF 3.9.5
- Gettext 0.18.1.1 (requires libiconv 1.14)
- ATK 1.32.0
- GLib 2.28.8
- GDK-Pixbuf 2.24.0
- FontConfig 2.8.0 (requires Expat 2.0.1 and Freetype 2.4.2)
- Pango 1.29.4 and Cairo 1.10.2 (requires Pixman 0.24.0)
- ..and finally, GTK+ 2.24.8
The build processI am assuming you are using bash (or a compatible) shell and are reasonably familiar with it. In order to reduce the length of commands that are needed, it is useful to set the following environment variables:
export LIBS=-static-libgcc export PATH=`pwd`/bin/:/build/bin/:$PATH export ZLIB=-L`pwd`/lib export ZINC=-I`pwd`/include export PFIX=/build export PKG_CONFIG_PATH=$PFIX/lib/pkgconfig/
The configuration command-lines for each of the packages is given below, and after each you need to also run
make && make install. The packages don't have to be built in this order, but this ordering has taken account of dependencies..
- libiconv-1.14, tiff-3.9.5, jpeg-8b, expat-2.0.1, freetype-2.4.2
- ./configure --prefix=$PFIX
- ./configure --prefix=$PFIX --enable-threads=win32 --enable-relocatable \ --with-iconv-prefix=$PFIX --without-libintl-prefix --with-included-gettext
- ./configure --prefix=$PFIX --with-expat=$PFIX --disable-docs
- env CFLAGS=$ZINC LDFLAGS=$ZLIB ./configure --prefix=$PFIX --disable-static --enable-shared
- env CFLAGS=$ZINC LDFLAGS=$ZLIB ./configure --prefix=$PFIX --with-threads=win32 --with-pcre=internal
- pixman-0.24.0, gdk-pixbuf-2.24.0
- env CFLAGS=$ZINC LDFLAGS=$ZLIB ./configure --prefix=$PFIX
- env CFLAGS=$ZINC LDFLAGS=$ZLIB ./configure --prefix=$PFIX --enable-full-testing
- ./configure --prefix=$PFIX
- ./configure --prefix=$PFIX --with-included-modules=yes
- env CFLAGS="$ZINC -I$PFIX/include" LDFLAGS="$ZLIB -L$PFIX/lib" ./configure --prefix=$PFIX \ --with-included-immodules=ime --enable-debug=no --disable-gtk-doc-html
Wrong libintl causing ld.exe to crashFor some reason MinGW's tends to be picked up rather than the one built from source. Symptoms are ld.exe crashing:
collect2: ld returned 5 exit status make: *** [gtk-update-icon-cache.exe] Error 1
Only working fix I know is to overwrite, rename, or delete
Use libpng v1.4.x, not v1.5.xThese two version series are not source-compatible, resulting in these errors:
io-png.c:681:32: warning: passing argument 5 of 'png_get_iCCP' from incompatible pointer type libpng15/png.h:2182:1: note: expected 'png_bytepp' but argument is of type 'char **' io-png.c: In function 'png_error_callback': io-png.c:772:30: error: dereferencing pointer to incomplete type io-png.c: In function 'real_save_png': io-png.c:981:12: error: dereferencing pointer to incomplete type io-png.c:1009:31: warning: pointer targets in passing argument 5 of 'png_set_iCCP' differ in signedness /libpng15/png.h:2189:1: note: expected 'png_const_bytep' but argument is of type 'gchar *'
Error 126 and/or Bad File Number (often gtk-update-icon-cache.exe)This is UAC kicking in at an unexpected point.
Making all in gtk ./gtk-update-icon-cache --force --ignore-theme-index \ --source builtin_icons stock-icons > gtkbuiltincache.h.tmp && \ mv gtkbuiltincache.h.tmp gtkbuiltincache.h /bin/sh: ./gtk-update-icon-cache: Bad file number make: *** [gtkbuiltincache.h] Error 126
Fastest fix is to run the MSYS Shell as administrator.
Missing libjpeg & libtiffThe JPEG and TIFF libraries are not listed as (sub-)dependencies on the GTK website, but building GDK-Pixbuf without them requires specific overriding using
Missing pthread libraryThis seems to be caused by an absence of the
If you see the following:
/bin/install -c -m 644 ./fonts.conf /build/etc/fonts/fonts.conf /build/bin/fc-cache -s -f -v C:/Windows/fonts:
It is not stuck. It doing some font-related caching, which might take quite a while. And yes, it does look rather like a prompt for input..
JPEG library build failsVersion 8c of the library does some things that older versions of GCC accepted, but will cause more recent versions to choke:
jcapimin.c:127:1: error: conflicting types for 'jpeg_suppress_tables' jcapimin.c:128:1: note: an argument type that has a default promotion can't match an empty parameter name list declaration jpeglib.h:984:14: note: previous declaration of 'jpeg_suppress_tables' was here make: *** [jcapimin.lo] Error 1 make: Leaving directory `/home/remy/gtk/jpeg-8c'
Version 8b does not seem to have this problem, so try using that version instead.
Unsupported hardware propertiesIf you get the following, you probably have a broken MSYS:
libtool: link: unsupported hardcode properties libtool: link: See the libtool documentation for more information. libtool: link: Fatal configuration error.
I am not sure of the root cause, but it seems to be the type of error that disappears as easily as it comes.
While pkg-config will happily use
PKG_CONFIG_PATH not working
PKG_CONFIG_PATH, the packages themselves install their manifests into $prefix/lib/pkg-config regardless of what
Trojan Horse Generic26 found!AVG seems to have a history of false positives with MinGW, and it is part of the more general problem of mixing patten-based virus scanners with compiler tool-chains. Configure scripts that compile/run/delete small test programs in quick succession are particularly prone to firing off virus alerts. This seems to happen quite frequently if you use mingw-get to grab (or update to) the latest compiler tools rather than an established snap-shot. Only fix I know, other than the non-option of disabling the virus scanner, is to install a clean copy of MinGW/MSYS and use it built-in package list.
RemarksDetails in this section are not strictly essential to the building process, but are included as they give the reasoning behind some of the process. This section will be most relevant if you are interested in variations such as using different package versions, and is intended to be more general than the errors described in the previous Pitfalls section.
Use of pkg-configIf you remember the olden days when packages came with configuration programs such as
sdl-config, the odds are you first came across pkg-config when a configuration script broke in some way. As a result it is very tempting to simply bypass pkg-config, but in this case it actually greatly simplifies you task once you get it working. The huge majority of the packages that make up GTK install pkg-config manifests as standard, negating the need for loads of
Why not Cygwin?I had originally looked into using Cygwin, but given how much MinGW/MSYS has improved since I first used it, Cygwin is an even more complicated process. Main problem Cygwin has is that you will have two build systems installed, and it is the non-default one you want to use for compiling GTK. If the build cannot find the MinGW-specific dependency, it will often include the Cygwin-based one instead, with inevitably bad results. A lot of the HOWTOs I've seen were based on the (now out of date) premise that MSYS was not mature enough to host the build system, so a hybrid of Cygwin and MinGW was needed.
Why not cross-compileAlthough I believe it would be a lot faster, it would have its own set of problems, the main one being difficulty in testing the compiled binaries. Wine is a great piece of software, but I don't think it is quite good enough for developmental work. Maybe a future work item..
zlib annoyancesCompared to all the other packages, zlib is a nightmare. When compiled under Windows the resultant library is not only broken, but you also have to mess around with
LDFLAGSvariables to get it to work. I suspect that zlib is mostly used as a sub-dependency of PNG support, but given how ubiquitous PNG is these days, leaving it out is no small trade-off.
How much from scratchOne of the original aims was to have everything built from scratch so that I had an audited set of DLLs and associated source code. However there are two components where this is difficult to achieve:
- Building this is a chicken-and-egg problem because it requires G-Lib, so it is easiest to simply grab the pre-built one from the GTK web-site. Since pkg-config is used as a tool within the build process rather than forming part of GTK, there are no licensing issues with this one.
- Don't bother building zlib from source. Under Windows, the resulting headers are broken in subtle ways, and to make thing even more confusing the result is linker errors.
No static build?My original plan was to make static builds as much as possible, allowing both GTK and all its dependencies to be consolidated into a small set of DLL files. Needless to say this is not a well-worn path for GTK. The configure scripts of GDK-Pixbuf and Pango specifically disallow it, the generated makefile for Fontconfig tries to install the DLL import library even though it has not been built, and even if the static libraries build/install properly you sometimes still need manual intervention to get them linked to. Concluded that the obtainable reductions (still over a dozen DLLs) were simply not worth the effort.
libPNG versionsGTK v2.16.x specifically looks for libPNG v1.2, but if it fails to find it the way it then tries to fall back to a non-specific version of libPNG often breaks. To make matters worse the later versions of some of the dependencies do not compile properly with libPNG v1.2, so you have to use v1.4 anyway. There is a PDF HOWTO that details the problem & solution, which amounts to copying libpng14 library files so that
-lpng14) will pick it up.
Don't use libPNG v1.5.x, as that version seems to be incompatible. Tried it myself, and ended up with build errors. For some reason libPNG treats minor version numbers as an indication of API changes.
GtkGlExt & fossilisation of GTK v2.16.xUnlike on Linux, the Windows GTK binaries do not include OpenGL support, and since the last 'release' tarball was back in 2006, building it means contending with all the bit-rot GTK v2.16 has accumulated. Considering the effort it takes to get any version of GTK built, I am disinclined to build a version that I suspect has (possibly recently) been discontinued.
I'm always a bit iffy about building developmental versions of (L)GPL software destined for Windows, but in the case of GtkGlExt, there is no choice. As is typical for repository-sourced versions, you need to generate the configuration scripts yourself, which apart from the README file being wrong (you actually run the bootstrap script, not autoconf.sh), does not actually work under MSYS. Mercifully the generated configure script itself is platform-independent, so I did the generation process under Linux then copied the resulting script across to Windows.