Compiling the GTK+ stack using Visual C++ 2008 and later

This will attempt to outline the process required to build the GTK+ stack (with the dependencies) on the latest Visual C++ as far as possible, as to address:

1. There are concerns on using different CRTs on Windows in terms of stability.
2. To help people integrate/develop/use GTK+ easier on Windows (especially under Visual Studio).
3. It is not possible to compile the latest stable GLib (at least) with Visual C++ 6 (or even 2003) out of the box-and it is required for the latest stable GTK+ 2.x/3.x, plus other GNOME software.
4. Many projects' latest sources require Visual Studio 2015 or later to build nowadays, including certain dependencies. Dependencies and items that require Visual Studio installations beyond 2008 and/or patching will be noted.

5. Unless building on an ARM64 system using Visual Studio 2022 17.4.x or later, omit the <build_test> (and so forth), since one cannot run ARM64 programs on x86/x64 systems.

6. Notice that DLL builds produced by Visual Studio 2015 or later should be ABI-compatible with any Visual Studio 2015 or later builds, provided that the compiler supports the compiler features required, unless otherwise noted.

Preparations

1. Please use 7-zip if you prefer to unpack the *.tar.xz tarballs via a GUI application, as it seems that WinRAR, although it supports unpacking *.tar.xz tarballs, it can mess up file permissions, causing odd security warnings to show up when opening Project Files from Visual Studio/Visual C++.

2. If you are building the GTK+ stack on CJK (Chinese, Japanese, Korean) versions of Windows, you will most likely see C4819 errors when attempting to build the stack, possibly accompanied by an error C2001 indicating new line in constant. Please do not attempt to save the relevant source file(s) with UTF BOM as it likely indicates that the stack has some parts that are not correctly built-this is due to an issue of the Visual C++ compiler running on CJK locales. To ensure that the code is correctly built in Visual Studio, please switch your non-Unicode locale (search under Google: "change the non-Unicode system locale" for how to do that for your version of Windows) to English (United States), reboot and rebuild, and things should build normally. This error would at least show up during the build of GLib, Pango, GTK+ (2.x and 3.x and master) and when their headers are used. This is also an issue that is faced when building some other open source projects with Visual Studio, such as OpenOffice/LibreOffice, Firefox, HarfBuzz, Qt, KDE projects, etc. Another alternative, if Visual Studio 2015 or later is used, is to use the /utf-8 compiler flag, but please be aware that for building certain items (such as libthai and amtk/tepl, issues may still be faced, unless one does the change of the system non-Unicode locale to English, as mentioned earlier).

3. Please use the latest Windows SDK (aka Platform SDK) and the latest Visual C++/Studio service pack available before you begin. If building with Visual Studio 2008, 2010 (and recommended for Visual Studio 2012), you will need to setup your development system to use the Windows 8.0/8.1 SDK. Please see https://devblogs.microsoft.com/cppblog/using-the-windows-8-sdk-with-visual-studio-2010-configuring-multiple-projects/ for details--basically, you need to ensure that the SDK include, library and tool directories are before the respective include, library and tool directories that come with your Visual Studio installation.

4. Please, ensure that your IDE and Visual C++ command line environment is working correctly before you begin. This includes making sure cl.exe (32-bit/64-bit) and ml.exe(32-bit)/ml64.exe(64-bit) can be run from your Visual C++ command prompt. Please, verify that your command prompt corresponds to the Visual C++ version you intend to use to compile the GTK+ stack and its corresponding applications. If you intend to build for ARM64 Windows, please note that many assembly/SIMD optimizations are currently unavailable, except the ones that are provided by Graphene.

5. Python 3.7.x or later with meson installed via pip. If building GObject-Introspection (g-i) or (gir or typelib) introspection files, the Python installation must match the architecture that you are building for, i.e. 32-bit Python for 32-bit/x86 builds and 64-bit (amd64) Python for 64-bit/x86-64 builds. Note that currently there is no official Python installer for ARM64 (aarch64) Windows, so building introspection files for ARM64 Windows is currently not supported, so for builds done with Meson one may need to pass in -Dintrospection=false or -Dgir=false (replace false with disabled if false is not accepted) in the meson command line)

6. CMake and Ninja (this is also provided by the Visual Studio 2017/2019/2022 installers). Note that when running CMake, gcc should not be in the %PATH%, which often happens when Cygwin or msys/msys2 executable folder are in the %PATH%.

7. For g-i, gstreamer, and building libsigc++-2.x and the -mm items, msys2 or Cygwin with some UNIX uttilities (meaning at least m4, cp, rm, flex and bison). As an alternative to flex and bison, win_flex and win_bison can be used instead of installing msys2 or Cygwin, for building gstreamer and g-i. For building libsigc++-2.x and the -mm items, you will also need a PERL installation with XML::Parser installed, which also requires libexpat.

8. Set up a working folder for this entire process, such as c:\gtk_compilation\$(VSVER)\$(Platform), as follows (c:\gtk_compilation will be denoted as $(workdir) in the below sections), where, :

$(Platform)

• Win32 (32-bit, x86 32-bit)

• x64 (64-bit, x86-64)

• arm64 (64-bit, aarch64) (Supported on Visual Studio 2017 15.9.x or later, or Visual Studio 2019 or 2022)

$(VSVER)

• vs9 (Visual Studio 2008)

• vs10 (Visual Studio 2010)

• vs11 (Visual Studio 2012)

• vs12 (Visual Studio 2013)

• vs14 (Visual Studio 2015)

• vs15 (Visual Studio 2017)

• vs16 (Visual Studio 2019)

• vs17 (Visual Studio 2022)

(Please note that for brevity, in the following sections c:\gtk_compilation\$(VSVER)\$(Platform) will be denoted as $(PREFIX))

mkdir $(PREFIX)
mkdir $(PREFIX)\bin
mkdir $(PREFIX)\include
mkdir $(PREFIX)\lib

It is recommended in the Visual Studio Command prompts that you do the following, which is useful for building CMake items at least:

set PATH=$(PREFIX)\bin;%PATH%;<path-to-python.exe>;<path-to-meson.exe>;<path-to-cmake.exe>;<path-to-ninja.exe>
set LIB=$(PREFIX)\lib;%LIB%
set INCLUDE=$(PREFIX)\include;%INCLUDE%

8. To build librsvg 2.42.x or later, you will need a Rust installation (with the Visual Studio/MSVC toolchain installed) and Visual Studio 2013 or later. ARM64 builds for librsvg *is* supported.

The Dependencies

Note that for Graphene, HarfBuzz and Cairo, these items will be listed under the GNOME items as they will use GNOME items along the way.

For CMake, <build_gen> can be Ninja, NMake Makefiles, Visual Studio xx. If using Visual Studio xx, also specify the architecture for the build via the -A flag, which can be x64, ARM64 or win32 (32-bit x86 Windows). Also specify the -DCMAKE_BUILD_TYPE=xxx if not using Visual Studio xx, which can be Release, RelWithDebInfo, Debug or MinSizeRel, and -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF to build the shared versions of the depedencies as far as possible, unless otherwise noted.

For Meson, the default <build_gen> will be Ninja (i.e. <build_gen> does not need to be specified unless using the Visual Studio projects). Although there is support for generating Visual Studio solution/project files for VS2010 or later (--backend=vs|vs2010|vs2012|vs2013|vs2015|vs2017|vs2019|vs2022), use of those is not that well supported, so your mileage might vary.

<build> refers to running ninja, nmake or opening the Visual Studio projects via the IDE or using MSBuild, depending on the <build_gen> that is used. <build_test> and <build_install> refers to executing the test and install targets (or project, if using the Visual Studio projects). You may want to copy the built PDB files if -DCMAKE_BUILD_TYPE=RelWithDebInfo is used, since the PDB files are not copied by CMake during install. For Meson builds, if Visual Studio 2008 is used, you need to embed the SxS manifest files after doing <build_install> using the mt.exe utility.

NASM (NMake Makefiles)

NASM is used when building libjpeg-turbo and OpenSSL on x86/x86_64 platforms; requires a PERL installation to build, such as ActiveState or Strawberry PERL Currently, Visual Studio NMake Makefiles in the latest 2.16.xx sources are not working, use 2.14.x or other prebuilt NASM binaries as a workaround.

cd $(srcdir)
nmake /f mkfiles\msvc.mak
copy /b nasm.exe $(PREFIX)\bin

BZip2/libbz2 (NMake Makefiles)

(Optionally used by FreeType and PCRE)

Unpack the latest release from https://www.sourceware.org/bzip2/, and unpack the zip/tarball to <workdir>

Find the lines in makefile.msc and change:

CFLAGS= -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo

-to-

CFLAGS= -DWIN32 -MD -Ox -GL -Zi -D_FILE_OFFSET_BITS=64 -nologo
(replace '-Ox -GL-' with '-Od' for debug builds)

and

        lib /out:libbz2.lib $(OBJS)

-to-

        link /LTCG /opt:ref /DEBUG /out:libbz2.dll $(OBJS) /def:libbz2.def
(omit '/LTCG /opt:ref' for debug builds)

In the Visual C++ command prompt, run the following:

cd $(the_folder_where_bzip2_was_unpacked)

nmake -f makefile.msc

Copy to $(PREFIX)\bin: libbz2.dll, libbz2.pdb, bzip2.exe, bzip2.pdb, bzip2recover.exe and bzip2recover.pdb<<br>> Copy to $(PREFIX)\lib: libbz2.lib<<br>> Copy to $(PREFIX)\include: bzlib.h<<br>>

liblzma (xz library) (Visual Studio Projects; one may wish to use CMake instead)

(Optionally used by libtiff and libxml2; requires Visual Studio 2013 or later; note that building the tools is not currently supported with Visual Studio build files)

Project files are found in $(srcdir)\windows. Visual Studio 2015 users should open the 2017 solution files and use the Visual Studio 2015 (v140) platform toolset.

Build the liblzma_dll project--building the ReleaseMT (using the static libcmt.lib CRT) is not recommended. Upon building, put the built liblzma.dll in $(PREFIX)\bin and put the built liblzma.lib in $(PREFIX)\lib. Copy everything as-is under $(srcdir)\src\liblzma\api (except Makefile.am and Makefile.in) in $(PREFIX)\include.

ICU (Visual Studio Projects, for 59.x or later)

This is the widely-used opensource library that is used to deal with Unicode, which is an optional dependency of libxml2; Visual Studio 2008~2013 users should look at the section with custom NMake Makefiles for ICU-58.x. This will require Visual Studio 2015 or later-if building for ARM64, build the x86/x64 versions before building for ARM64.

1. Grab the latest sources for ICU4C from http://site.icu-project.org/, and unpack the sources somewhere.

2. Open the solution file in $(top_srcdir)\source\allinone\allinone.sln, and build your desired configuration.

3. Copy the .lib files in $(top_srcdir)\source\lib (32-bit builds) or $(top_srcdir)\source\lib64 (64-bit builds) to $(PREFIX)\lib\, copy the DLLs and .exe files in $(top_srcdir)\source\bin (32-bit builds) or $(top_srcdir)\source\bin64 (64-bit builds) to $(PREFIX)\bin, and everything in $(top_srcdir)\source\include to $(PREFIX)\include.

ZLib, libpng, libjpeg-turbo, liblzma, libtiff, libexpat, libxml2, pcre/pcre2, brotli, FreeType2, SDL-2.x (CMake)

• ZLib is required by many of the dependencies as well as GIO and GdkPixbuf and Cairo; you may want to make a copy or symlink of zlib.lib to $(PREFIX)\lib\zlib1.lib for convenience

• libpng is required by GDK-Pixbuf, Cairo and the latest stable GTK-4.x or later; -DPNG_STATIC=OFF is for building libpng only

• libjpeg-turbo is required by libtiff, GDK-Pixbuf and the latest stable GTK-4.x; -DENABLE_STATIC=OFF, -DWITH_JPEG7=ON and -DWITH_JPEG8=ONare for libjpeg-turbo only. Only one of -DWITH_JPEG7=ON or -DWITH_JPEG8=ON may be used, to mimick the IJG libjpeg 7 or IJG libjpeg 8 APIs/ABIs, if needed.

• liblzma is optionally used by libxml2 and libtiff; CMake build files are included from 5.4.0 and 5.2.10 at least without the support to build the tools; requires Visual Studio 2013 or later
• libtiff is optionally used in GDK-Pixbuf and the latest stable GTK-4.x; 4.3.0 or later require Visual Studio 2015 or later

• libexpat is required by FontConfig-its Meson build files do not yet support libxml2 builds, 2.3.x require Visual Studio 2013 or later, 2.4.x and later require Visual Studio 2015 or later

• brotli is optionally used by FreeType, requires Visual Studio 2013 or later

• FreeType2 is recommended for building HarfBuzz and Cairo, and is required by PangoFT2 and FontConfig if built. You may wish to first build FreeType, and then build HarfBuzz against this build of FreeType, and then rebuild FreeType on top of the HarfBuzz build that was built against FreeType for a more feature-comprehensive build of FreeType

• PCRE is required by GLib-2.72.x or earlier and PCRE2 is required by GLib-2.74.x or later, and by GtkSourceview 5.x; the latest PCRE2 sources require Visual Studio 2013 or later without patching

• SDL-2.x is optional for Cogl, and is a widely-used library for game and multimedia programming, -DSDL_STATIC is only used for building SDL-2.x; the latest versions may need to be patched to build on Visual Studio 2008 32-bit; 64-bit builds build out of the box even on Visual Studio 2008

Do the following:

1. Download and unpack the sources somewhere.
2. Run the following:

md $(top_builddir) & cd $(top_builddir)

cmake $(top_srcdir) -G <build_gen> -DCMAKE_INSTALL_PREFIX=$(PREFIX) <-DPNG_STATIC=OFF> <-DENABLE_STATIC=OFF> <-DWITH_JPEG[7|8]=ON> <-DSDL_STATIC=OFF>

<build> & <build_test> & <build_install>

libANGLE (NMake Makefiles for copy bundled in QT-5.x)

This is recommended for maximum compatibility for OpenGL support on Windows in GTK, and is needed for GL to work if running on ARM64 platforms without the OpenGL compatibility pack (which, is, in essence a build of Mesa for ARM64 with the D3D12 backend enabled).

It is the easiest to use the libANGLE that is bundled with Qt; please note that for best experience the libANGLE from QT 5.10.1 is recommended--note that the libANGLE in 5.10.1 requires Visual Studio 2013 or later to build, and later versions require Visual Studio 2015 or later. The Visual Studio 2013 builds of libANGLE can be used for GTK built with Visual Studio 2008 to 2013; and the Visual Studio 2015 builds of libANGLE may only be used for Visual Studio 2015 (or later) builds of GTK. Note that QT-6.x do not ship with libANGLE.

Note that you do not need to download the full QT5.x sources to obtain libANGLE--it is found in the qtbase source package. Follow the official QT build instructions to build qtbase--you may wish to pass in -nomake examples -nomake tests to qtbase's configure command line to save time; additionally, if you do not need to use the rest of QT, you may ctrl-C to cancel the build right after the libANGLE DLLs (libGLESv2.dll and libEGL.dll) are built, and go to $(top_builddir)\src\angle and run nmake install to install the libANGLE headers, lib's and DLLs, and note that libANGLE's headers will be installed in $(prefix)\include\QtAngle.

If you wish to carry out a cross-build of QtBase (libANGLE) on an x86 or x86-64 machine to an ARM64 system, follow the instructions from https://doc.qt.io/qt-5/winrt-support.html on building Qt for UWP, but replace the -xplatform winrt-x64-msvc2017 to -xplatform win32-arm64-msvc2017.

Please note that for libepoxy to use EGL (libANGLE) support, it must be explicitly enabled by -Degl=yes, and the libANGLE headers can be found by putting $(prefix)\include\QtAngle in the paths pointed to by %INCLUDE%, and libEGL.lib and libGLESv2.lib can be located by the linker during libepoxy's configuration stage. At run time, libepoxy needs to be able to load libGLESv2.dll and libEGL.dll.

Pixman, FontConfig, libepoxy, libpsl (Meson)

• Pixman is required for Cairo; for building ARM64 binaries, also pass in -Da64_neon=disabled in the command line below since the ARM64 assembly routines are not currently buildable by compilers targeting Windows; the --pkg-config-path=... and --cmake-prefix-path=... arguments are not needed

• FontConfig is required if FontConfig/Freetype support is needed in Pango and Cairo; FreeType and Expat are required, as well as a copy of gperf in your %PATH% which can be obtained from MSYS2; Visual Studio 2015 or later are required to build the sources out-of-the-box; if using gperf from MSYS2, it is recommended to have MSYS2's executables directory at the end of your %PATH%

• libepoxy is needed to build GTK-3.16.x or later and GTK-4.x, the -Degl=yes option is only for building libepoxy and is used to enable EGL/GLES support if libANGLE is installed; you need to obtain a working stdint.h for Visual Studio 2008 and a working inttypes.h and a working stdbool.h for Visual Studio 2008~2012; you may be able to get these headers from cloning the https://github.com/fanc999/gtk-deps-msvc/ and look under libiconv\1.17\msvc\srclib

• libpsl is required by libsoup, and requires ICU for full functionality

Do the following:

1. Download the latest release and unpack it somewhere.
2. Run the following:

md $(top_builddir) & cd $(top_builddir)

$(MESON) $(top_srcdir) <build_gen> --buildtype=<buildtype> --prefix=$(PREFIX) --pkg-config-path=$(PREFIX)\lib\pkgconfig --cmake-prefix-path=$(PREFIX) <-Degl=yes>

<build_test> & <build_install>

libiconv, gettext, libffi, ICU (Custom NMake Makefiles)

• libiconv is used by gettext, and optionally used by libxml2
• gettext is used in many components of the GTK+ stack, the custom NMake Makefiles will build the runtime, the C# DLLs if Visual C# is installed, as well as the utilities; gettext 0.21.1 and later require Visual Studio 2015 or later

• ICU is optionally used by HarfBuzz, sqlite and libxml2, and is very commonly utilized--this section here is mainly for building ICU-58.x for Visual Studio 2008~2013; Visual Studio 2015 or later should use the project files provided with the later ICU releases directly

Do the following:

1. Clone the repository https://github.com/fanc999/gtk-deps-msvc, and note the versions supported for each of the dependencies in the checkout (the subdirectory in each dependency will depict at least the latest major version that is supported with the custom NMake Makefiles), and download the sources of the corresponding versions of the dependencies and unpack them. Apply all the relevant patches and copy the win32 directory to $(top_srcroot).

2. Run the following:

cd $(top_srcdir)\win32
nmake /f Makefile.vc CFG=[debug|release] PYTHON=$(PYTHON) PREFIX=$(PREFIX)
nmake /f Makefile.vc CFG=[debug|release] PYTHON=$(PYTHON) PREFIX=$(PREFIX) install

OpenSSL (NMake Makefiles)

This is used for glib-networking for SSL/TLS support, which is in-turn used by libsoup at runtime. Using libreSSL is currently not well-tested and using any releases before 1.1.1x is not recommended.

Requires a PERL installation, NASM for x86/x64 builds, and optionally ZLib.

This covers on building Openssl-1.1.1x; building for Opensl-3.x is largely the same.

Do the following:

1. Download the lateset sources from the OpenSSL website, and unpack the sources somewhere.

2. Run the following (this will take a while; <PLAT> refers to VC-WIN32 [32-bit x86 build], VC-WIN64A [64-bit x64 build] and VC-WIN64-ARM [ARM64 build]; for <options>, also put in zlib if enabling ZLib support and whatever additional ciphers/features desired for the build-see the OpenSSL build documentation; for $(PREFIX), use forward slashes, not backward (Windows-style) ones)

md $(top_builddir) & cd $(top_builddir)
$(PERL) $(top_srcdir)\Configure <PLAT> <options> --prefix=$(PREFIX)
nmake & nmake test & nmake install

Sqlite (manual build)

Required by libsoup, is a widely-used software library. Optionally uses ICU.

1. Download the amalgamation sources with autoconf.

2. Run the following (omit /DSQLITE_ENABLE_ICU and /libpath:$(PREFIX)\lib icuin.lib icuuc.lib if ICU support is not desired, replace /MD /O2 /GL with /MDd /Od and omit /opt:ref /LTCG for debug builds)

cd $(top_srcdir)

nmake /f makefile.msc sqlite3res.lo

cl /W3 /MD /O2 /GL /Zi /DSQLITE_ENABLE_COLUMN_METADATA /DSQLITE_ENABLE_FTS4 /DSQLITE_ENABLE_FTS5 /DSQLITE_ENABLE_ICU /DSQLITE_ENABLE_RTREE /DSQLITE_ENABLE_MATH_FUNCTIONS /DSQLITE_API=__declspec(dllexport) sqlite3.c /link /DEBUG /opt:ref /LTCG /DLL /out:$(PREFIX)\bin\sqlite3.dll /implib:$(PREFIX)\lib\sqlite3.lib sqlite3res.lo /libpath:$(PREFIX)\lib icuin.lib icuuc.lib

del $(PREFIX)\lib\sqlite3.exp

for %f in (sqlite3.h sqlite3ext.h) do copy %f $(PREFIX)\include

// Omit if not building the sqlite3 shell program
cl /W3 /MD /O2 /GL /Zi shell.c /Fe$(PREFIX)\bin\sqlite3.exe /link /DEBUG /opt:ref /LTCG $(PREFIX)\lib\sqlite3.lib /pdb:$(PREFIX)\bin\sqlite3-shell.pdb

GNOME items (including Graphene, HarfBuzz and Cairo)

Whew-it's a long list of dependencies, huh? Now, we are ready to build the GTK+ stack-note that I am listing Cairo in this section because Cairo optionally depends on GObject (but this optional dependency of Cairo on GObject is a hard requirement for GTK+-3.x and Clutter 1.6+)

GLib

This set of libraries forms the basis of the GTK+ (GNOME) stack, required by all parts of the GTK+ core stack (ATK, Pango, GDK-Pixbuf, GTK+) and most GNOME components, such as COGL and Clutter.

This package requires gettext-runtime, ZLib and libFFI (libFFI is required for GLib 2.29.x or later only). PCRE is optionally required-it is included in the GLib tarball.

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C+ solution file in GLib's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010). If you like to use your own copy of PCRE, use the configurations with the _ExtPCRE suffix.
3. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, utilities and headers put in their appropriate places.

4. If you plan to compile COGL (and Clutter), you will need to open $(srcroot)\gobject\glib-mkenums.in, find the line:

   print "glib-mkenums version glib-@GLIB_VERSION@\n";

   and replace @GLIB_VERSION@ to be the version of GLib that you have just compiled. Save the file as c:\gtk_compilation\$(VS_VER)\$(Platform)\bin\glib-mkenums--this is the PERL script that is used by some GNOME libraries to generate enumeration sources at compile time, if it is not already installed by the build process.

ATK

This library acts as the accessibility layer for GNOME/GTK+, and is also used by Clutter.

This package requires GLib and gettext-runtime.

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C+ solution file in ATK's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010).
3. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs and headers put in their appropriate places.

GDK-Pixbuf

This library forms the basis of image loading and handling in GTK+ and GNOME, and is also used by COGL.

This package requires LibPNG, ZLib, gettext-runtime and GLib at the minimum. You will need to also build and install the IJG JPEG, LibTIFF and JASPER (JEPG-2000 library) beforehand if you choose not to use GDI+ (the *_NoGDIP configurations; the GDI+ headers and libraries are part of the standard Windows/Platform SDK installation).

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C+ solution file in GDK-Pixbuf's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010).
3. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, utilities and headers put in their appropriate places.

Cairo

[ (2014/02/10, 2014/08/06): Please note, if you are attempting to build the stack with Visual Studio 2010 and later, you will most probably need to turn off Whole Program Optimization as this likely means a bug in Cairo and/or the Visual Studio Optimization which will likely cause cairo to assert and crash in cairo-polygon.c in line 296]

This is not a GNOME component by itself, but is used and required by Pango, GTK+ and COGL/Clutter. Note that in order to build and run GTK+3.x and Clutter, GObject support is also required. Please get the latest possible version of the 1.12 release series as many Windows functionality and stability bugs were fixed in the later 1.12.x versions, and they incorporate the patches that Alexander Larsson submitted to Cairo that fix the redrawing bugs on Windows.

This package requires GLib, LibPNG, ZLib and Pixman; if building Pango with FontConfig support, FreeType and Expat are also required.

1. Grab the latest stable 1.12.x sources from http://cairographics.org, and unpack the tarball in c:\gtk_compilation\.

2. Get the VS project files from cairo-vsprojects.zip, and unzip the file in Cairo's $(srcroot)

3. Decide whether FontConfig support is needed (hint: are you planning to build GIMP with this? Are you using FontConfig in any other way?). Open cairo-vs9.sln or cairo-vs10.sln (VS 2008 or VS2010 respectively without FontConfig support); or open cairo-fc-vs9.sln or cairo-fc-vs10.sln (VS2008 or VS2010 respectively with FontConfig support). Select your configuration and build Cairo. The *_GL configs do not currently build as they require GL extensions which is unable to link properly on Windows.

4. Note that Cairo and cairo-gobject are built into 2 seperate DLLs. The build results will be copied to c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs and headers put in their appropriate places.

Pango

This set of libraries handles the (natural) language scripting and language handling parts of GTK+ and GNOME, including COGL and Clutter.

This package depends on Cairo and GLib at the minimum. If you want to build Pango with FontConfig support, you also need to build and install FontConfig (and its dependencies) beforehand, and your Cairo must also be built with FontConfig support.

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C++ solution file in Pango's $(srcroot)\build\win32\$(VS_VER).

3. Open pango.sln (if not building with FontConfig support) or pango_fc.sln (if building with FontConfig support), and select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs and headers put in their appropriate places.

GTK+

Finally, we are getting into building GTK+! It has sure been a long way to get to this point!

This package depends on GLib, ATK, Pango (note that FontConfig support is not absolutely required!), GDK-Pixbuf and Cairo and their dependencies. Again, if you are building GTK+-3.x, Cairo must be built with GObject support. If you are building GTK+-3.8.x or later, you need to have Python 2.5.x or later or 3.x installed, and check whether the PythonPath entry in gtk-version-paths.vsprops (or gtk-version-paths.props) points to the correct folder where the Python executable can be found. A standard Windows binary (x86 or amd64/x86-64) from http://www.python.org will do.

1. Grab the latest stable/unstable 2.24.x/3.x tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C+ solution file in GTK+'s $(srcroot)\build\win32\$(VS_VER).
3. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, demo program and headers put in their appropriate places. This will conclude building the GTK+ stack with MSVC all the way through.

Note though, there are two more steps that are needed, one is to download a custom index.theme file from index.theme into c:\gtk_compilation\$(VS_VER)\$(Platform)\share\icons\hicolor (create the folder if needed) and get the latest stable adwaita-icon-theme package from Adwaita Icon Theme and put that archive into c:\gtk_compilation. Do the following:

1. Using a shell (such as MSYS, mozilla-build or cygwin), go to c:\gtk_compilation and run: tar -Jxvf adwaita-icon-theme-(x.y.z).tar.xz, where x.y.z stands for the release version numbers, such as 3.14.0. Copy all of the contents of in the Adwaita folder in the extracted folder to c:\gtk_compilation\$(VS_VER)\$(Platform)\share\icons\hicolor. You will need the xz utility if one is not already on your system, and it must be in your PATH if it is not bundled with your MSYS, mozilla-build or cygwin. A copy of xz-utils can be obtained from http://www.tukaani.org/xz/. Please, do not use 7-zip or WinRAR for this if you intend to use the SVG-format symbolic icons in any way, as some of the scalable SVG icons will be incorrectly extracted-this part will be updated once this problem is resolved.

2. Get the .zip file containing the symbolic icons that have been converted to PNG format from here and unzip it into c:\gtk_compilation\$(VS_VER)\$(Platform)\share\icons\hicolor.

libxml2

This is the libxml2 library that is used in GNOME to parse XML, and is a required depedency of libcroco, librsvg and gtksourceview. This library is listed here, although it does not hard-depend on other GNOME libraries, as it is a GNOME library by itself. This library optionally depends on ZLib, iconv and ICU.

1. Get the latest libxml2 release tarball from http://xmlsoft.org/, and unpack it in c:\gtk_compilation.

2. Open win32\Makefile.msvc in the libxml2 sources, and add this line after CFLAGS = $(CFLAGS) /I$(XML_SRCDIR) /I$(XML_SRCDIR)\include /I$(INCPREFIX):
   CFLAGS = $(CFLAGS) /Ic:\gtk_complation\$(VS_VER)\$(Platform)\include.
   Add this line after LDFLAGS = $(LDFLAGS) /LIBPATH:$(BINDIR) /LIBPATH:$(LIBPREFIX):
   LDFLAGS = $(LDFLAGS) /LIBPATH:c:\gtk_compilation\$(VS_VER)\$(Platform)\lib.

3. Find and change the following: (If using ZLib) zdll.lib to zlib1.lib (Release) or zlib1d.lib (debug); (If using ICU) icu.lib to icuuc.lib (Release) or icuucd.lib (debug).

4. Using a Visual Studio (or Windows SDK) command prompt, go to the win32\ folder and run the following: cscript configure.js zlib=yes icu=yes iconv=no prefix=c:\gtk_compilation\$(VS_VER)\$(Platform). You need to explicitly specify zlib=yes and icu=yes if you want to use ZLib or ICU, and explicitly specify iconv=no if iconv support is not desired.

5. Run nmake followed by nmake install (Release builds) or nmake DEBUG=1 followed by nmake DEBUG=1 install (Debug builds)

Going further

Note that this section may grow as time progresses, but I can't say when now.

JSON-GLib

This library is the GLib implementation of JSON scripting, and is used by the Clutter toolkit.

This library depends on GLib.

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\.
2. Open the Visual C+ solution file in JSON-GLib's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010).
3. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, test programs and headers put in their appropriate places.

GObject-Introspection (g-i)

This is the package where one can create language bindings dynamically with the GTK+/Clutter stack.

This package requires the installation of the following items:

• -GLib, as outlined above
  -LibFFI, as outlined above
  -Python 2.7 installation which matches your build config (Win32 or x64)(An official Python binary distribution will suffice. Python 3.x is unfortunately *not* supported at this time)-note that this limitation is only related to the build of the introspection files, PyGObject will work with Python-2.7.x or Python 3.1+
  -A MinGW gcc installation, this is needed as the source scanner will need a GCC preprocessor to process the headers/sources during the .gir/.typelib generation. You will need a 32-bit MinGW/GCC for 32-bit/x86 builds and a x64/x86-64 bit MinGW gcc for 64-bit builds. These can be obtained from the official MinGW site (32-bit MinGW only) and the mingw-w64 site (both 32-bit and 64-bit versions of MinGW). Work is under way to remove the GCC build-time requirement.
  -Set of pkg-config files for at least the GLib components. A sample set is available here: pkgconfig_sample_file.zip-you will need to edit those files to reflect your build/execution environment (in particular the prefix, exec_prefix, includedir and libdir). You will need to have one separate copy for each configuration (i.e. Win32/x86 vs x64, VS 2008 vs VS2010 vs VS2012 vs VS2013).

The steps to build g-i and the typelibs are outlined as follows:

1. Grab the latest stable/unstable tarball from the GNOME FTP. Unpack the tarball in c:\gtk_compilation\
2. Open up a Visual C++ 2008/2010 command prompt that matches your build configuration. (Visual C++/Studio Express users will need to use a Windows SDK command prompt for x64 builds)
3. In the command prompt, go to the base directory where you extracted the GObject-Introspection sources.

   • 4.1 Check whether the definitions of PythonDir and/or PythonDirX64 matches your installation path of Python 2.6.x or 2.7.x in gi-extra-paths.vsprops or gi-extra-paths.props.
     
     

     4.2 Open the desired .sln file under build/win32/vs9 or build/win32/vs10, select your desired configuration (Win32 vs x64 and Debug vs Release), and build. The g-i headers, g-i .lib (girepository-1.0.lib, g-i DLL and tools and scripts, and the g-i scanner Python 2.x module will be installed in their appropriate places in c:\gtk_compilation\$(VS_VER)\$(Platform). Note that building the introspection files is not yet done at this point.
     
     4.3 Now we need to build the introspection files for g-i and GLib (and for libxml2, fontconfig, freetype and Cairo-GObject, and OpenGL and Win32. Open a Visual Studio (or Windows SDK) command prompt that matches your build config and navigate to c:\gtk_compilation\gobject-introspection-x.yy.z\build. Set these as environment variables or pass them in during the invocation of gi-introspection-msvc.mak (for example: nmake -f gi-introspection-msvc.mak CFG=release PYTHON2=c:\python27\python.exe PKG_CONFIG_PATH=c:\pkgconfig.vs9.win32 MINGWDIR=c:\mingw32).:

   • CFG: Build type of the g-i libraries and tools, either "release" or "debug"
   • MINGWDIR: Base directory where your MinGW/GCC installation resides, where your gcc executable resides in %MINGWDIR%\bin\gcc.exe. The installation must match your build configuration (i.e. Win32 or x64)
   • PYTHON2: (Optional if the python interpreter, python.exe, for Python 2.6.x/2.7.x is in your PATH) Location of your Python 2.6.x/2.7.x installation. The installation must match your build configuration (i.e. Win32 or x64).

   • PKG_CONFIG_PATH: Location of your GLib and possibly dependent .pc files, as mentioned previously
     
     

     Invoke the NMake Makefile gi-introspection-msvc.mak using nmake -f gi-introspection-msvc.mak <options, as noted above if not set as environment variables>. If you see Error 145 during the build of the introspection files, retry this command again, and it should work. Upon successful build, you will see a number of .gir/.typelib files in the current directory.
     
     

     4.4 Install the intropsection files using nmake -f gi-introspection-msvc.mak <options> install-introspection. If cleaning the output is desired, use nmake -f gi-introspection-msvc.mak clean

Building the Introspection Files for the other packages

This mainly covers how the introspection files for the various GNOME bits are built, g-i needs to be built and installed beforehand. Note that the introspection files for GLib (GIO/GObject/GModule/GThread/GLib) and g-i are already covered during the build process of g-i. This is supported for all the GNOME packages listed in this post, except for libxml2, libcroco, Cogl and Clutter.

1. Make sure that the GNOME project in which generating the introspection files are already built in your desired configuration. Then open a Visual Studio (or Windows SDK) command prompt that matches your build configuration and with it navigate to the "build" folder (or "build/win32" folder for JSON-GLib), where there will be a <project_name_or_project_name_initials>_introspection-msvc.mak NMake Makefile. Set or pass in the following environment variables (see section 4.x from g-i) to <project_name_or_project_name_initials>_introspection-msvc.mak (which stand for the <options> part below:

   • CFG: Build type of the g-i libraries and tools, either "release" or "debug"
   • MINGWDIR: Base directory where your MinGW/GCC installation resides, where your gcc executable resides in %MINGWDIR%\bin\gcc.exe. The installation must match your build configuration (i.e. Win32 or x64)
   • PYTHON2: (Optional if the python interpreter, python.exe, for Python 2.6.x/2.7.x is in your PATH) Location of your Python 2.6.x/2.7.x installation. The installation must match your build configuration (i.e. Win32 or x64)

   • PKG_CONFIG_PATH: Location of your GLib and possibly dependent .pc files, as mentioned previously
     
     

     Run nmake -f <project_name_or_project_name_initials>_introspection-msvc.mak <options> to build the introspection files for the project, followed by nmake -f <project_name_or_project_name_initials>_introspection-msvc.mak <options> install-introspection to install the introspection files to their appropriate places under c:\gtk_compilation\$(VS_VER)\$(Platform). Use nmake -f <project_name_or_project_name_initials>_introspection-msvc.mak clean to clean up the build of introspection.

Cogl

This package forms the abstraction of OpenGL usage across various different platforms, and is currently mainly utilized by the Clutter toolkit. This will build both the Cogl main library and the Cogl-Pango library.

This package requires GDK-Pixbuf, Pango, Cairo, GLib and gettext-runtime, and it also requires the glext.h header from http://www.opengl.org/registry/api/glext.h. A working PERL interpretor is also required here, and the PERL interpretor must be in your PATH (it is done for you if you install a pre-packaged PERL interpreter using an installer, such as ActiveState PERL). If building the SDL backend (winsys) is desired, the SDL library is also required. This currently will build COGL with the Win32/WGL backend for all builds, and will also build the SDL backend if one chooses to do so.

1. Place the glext.h header from http://www.opengl.org/registry/api/glext.h in c:\gtk_compilation\$(VS_VER)\$(Platform)\include\GL. You will also need glib-mkenums from GLib to be in c:\gtk_compilation\$(VS_VER)\$(Platform)\bin (please see step 4 of GLib). If you are intending to build and run COGL 1.14.x or later, you will need to obtain a compatible stdint.h implementation from http://code.google.com/p/msinttypes/ if you are running Visual C++ 2008, where you will need to place the stdint.h from the downloaded archive into c:\gtk_compilation\$(VS_VER)\$(Platform)\include. Visual C++ 2010 ships with stdint.h by default.

2. Grab the latest stable/unstable tarball from the GNOME FTP. If building Cogl-1.10.0, you will also need to download the cogl.symbols from here and replace the one in $(srcroot)\cogl after you unpacked the Cogl sources. Unpack the tarball in c:\gtk_compilation\.

3. The Visual C+ solution files can be found in Cogl's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010). Decide whether the use of the SDL backend (the SDL backend seems experimental on Windows) is desired, and open cogl.sln (Windows/WGL backend only) or cogl_sdl.sln (both Windows/WGL and SDL backends)
4. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, example programs, test programs and headers put in their appropriate places.

Clutter

This package is the Clutter toolkit (library), which is used to create fast, portable and compelling user interfaces.

This package requires COGL (with the dependent glext.h-please see item 1 from COGL), JSON-GLib, ATK, Pango, Cairo, GLib and gettext-runtime. If using the GDK backend is desired, you will also need GDK-3.x, version 3.4 or later, which is included in the GTK-3.x package. A working PERL interpretor is also required here, and the PERL interpretor must be in your PATH (it is done for you if you install a pre-packaged PERL interpreter using an installer, such as ActiveState PERL).

Please note that all configurations will include Win32/WGL backend (which is the default backend used on Windows), and the GDK backend can be built using the configurations that end with _GDK. You will need to override the backend in your code or use "set CLUTTER_BACKEND=gdk" to use the GDK backend.

1. You will again need glib-mkenums from GLib to be in c:\gtk_compilation\$(VS_VER)\$(Platform)\bin (please see step 4 of GLib).
2. Grab the latest stable/unstable tarball from the GNOME FTP (the stable tarballs do not yet have Visual C++ project files in them yet-this will be updated when the situation changes here). Unpack the tarball in c:\gtk_compilation\.
3. Open the Visual C+ solution file in Clutter's $(srcroot)\build\win32\vs9 (VS 2008) or $(srcroot)\build\win32\vs10 (VS2010).
4. Select your desired configuration and build within the Visual C++ IDE. Upon successful compilation, the build results will end up in c:\gtk_compilation\$(VS_VER)\$(Platform), with the DLLs, LIBs, example programs, test programs and headers put in their appropriate places.

[1]: It may not be possible to convert Visual C++ 6 .dsw/.dsp files to Visual C++ 2010 .sln/.vcxproj files directly. This is a known issue on Microsoft, and sorry for not posting earlier about this. Please see http://www.beta.microsoft.com/VisualStudio/feedback/details/584501/converting-vc6-dsp-files-with-vc2010-express for more details about this.