| The Win32 backend in GTK+ is not as stable or correct as the X11 one. | |
| For prebuilt runtime and developer packages see | |
| http://ftp.gnome.org/pub/gnome/binaries/win32/ | |
| Building GTK+ on Win32 | |
| ====================== | |
| First you obviously need developer packages for the compile-time | |
| dependencies: GDK-Pixbuf, Pango, atk, glib, gettext-runtime, libiconv at least. | |
| See http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies . | |
| For people compiling GTK+ with Visual C++ or later, it is recommended that | |
| the same compiler is used for at least GDK-Pixbuf, Pango, atk and glib | |
| so that crashes and errors caused by different CRTs can be avoided. Currently | |
| building with Visual Studio 2008 or later is supported, either via Visual Studio | |
| project files or via the Meson build system, as described in the below sections. | |
| Interchanging between Visual Studio 2015, 2017 and 2019 builds should be fine | |
| as they use the same CRT (UCRT) DLLs. | |
| After installing the dependencies, there are two ways to build GTK+ | |
| for win32. | |
| 1) GNU tools, ./configure && make install | |
| ----------------------------------------- | |
| This requires you have mingw and MSYS. | |
| Use the configure script, and the resulting Makefiles (which use | |
| libtool and gcc to do the compilation). I use this myself, but it can | |
| be hard to setup correctly. | |
| The full script I run to build GTK+ 2.16 unpacked from a source | |
| distribution is as below. This is from bulding GTK+ 2.16.5. I don't | |
| use any script like this to build the development branch, as I don't | |
| distribute any binaries from development branches. | |
| # This is a shell script that calls functions and scripts from | |
| # tml@iki.fi's personal work envíronment. It is not expected to be | |
| # usable unmodified by others, and is included only for reference. | |
| MOD=gtk+ | |
| VER=2.16.5 | |
| REV=1 | |
| ARCH=win32 | |
| THIS=${MOD}_${VER}-${REV}_${ARCH} | |
| RUNZIP=${MOD}_${VER}-${REV}_${ARCH}.zip | |
| DEVZIP=${MOD}-dev_${VER}-${REV}_${ARCH}.zip | |
| HEX=`echo $THIS | md5sum | cut -d' ' -f1` | |
| TARGET=c:/devel/target/$HEX | |
| usedev | |
| usemsvs6 | |
| ( | |
| set -x | |
| DEPS=`latest --arch=${ARCH} glib atk cairo pango libpng zlib libtiff jpeg` | |
| PROXY_LIBINTL=`latest --arch=${ARCH} proxy-libintl` | |
| PKG_CONFIG_PATH= | |
| for D in $DEPS; do | |
| PATH=/devel/dist/${ARCH}/$D/bin:$PATH | |
| [ -d /devel/dist/${ARCH}/$D/lib/pkgconfig ] && PKG_CONFIG_PATH=/devel/dist/${ARCH}/$D/lib/pkgconfig:$PKG_CONFIG_PATH | |
| done | |
| LIBPNG=`latest --arch=${ARCH} libpng` | |
| ZLIB=`latest --arch=${ARCH} zlib` | |
| LIBTIFF=`latest --arch=${ARCH} libtiff` | |
| JPEG=`latest --arch=${ARCH} jpeg` | |
| patch -p0 <<'EOF' | |
| EOF | |
| lt_cv_deplibs_check_method='pass_all' \ | |
| CC='gcc -mtune=pentium3 -mthreads' \ | |
| CPPFLAGS="-I/devel/dist/${ARCH}/${LIBPNG}/include \ | |
| -I/devel/dist/${ARCH}/${ZLIB}/include \ | |
| -I/devel/dist/${ARCH}/${LIBTIFF}/include \ | |
| -I/devel/dist/${ARCH}/${JPEG}/include \ | |
| -I/devel/dist/${ARCH}/${PROXY_LIBINTL}/include" \ | |
| LDFLAGS="-L/devel/dist/${ARCH}/${LIBPNG}/lib \ | |
| -L/devel/dist/${ARCH}/${ZLIB}/lib \ | |
| -L/devel/dist/${ARCH}/${LIBTIFF}/lib \ | |
| -L/devel/dist/${ARCH}/${JPEG}/lib \ | |
| -L/devel/dist/${ARCH}/${PROXY_LIBINTL}/lib -Wl,--exclude-libs=libintl.a \ | |
| -Wl,--enable-auto-image-base" \ | |
| LIBS=-lintl \ | |
| CFLAGS=-O2 \ | |
| ./configure \ | |
| --enable-win32-backend \ | |
| --disable-gdiplus \ | |
| --with-included-immodules \ | |
| --without-libjasper \ | |
| --enable-debug=yes \ | |
| --enable-explicit-deps=no \ | |
| --disable-gtk-doc \ | |
| --disable-static \ | |
| --prefix=$TARGET && | |
| libtoolcacheize && | |
| rm gtk/gtk.def && | |
| (PATH="$PWD/gdk-pixbuf/.libs:/devel/target/$HEX/bin:$PATH" make -j3 install || (rm .libtool-cache* && PATH="/devel/target/$HEX/bin:$PATH" make -j3 install)) && | |
| PATH="/devel/target/$HEX/bin:$PATH" gdk-pixbuf-query-loaders >/devel/target/$HEX/etc/gtk-2.0/gdk-pixbuf.loaders && | |
| grep -v -E 'Automatically generated|Created by|LoaderDir =' <$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders >$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp && | |
| mv $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders && | |
| grep -v -E 'Automatically generated|Created by|ModulesPath =' <$TARGET/etc/gtk-2.0/gtk.immodules >$TARGET/etc/gtk-2.0/gtk.immodules.temp && | |
| mv $TARGET/etc/gtk-2.0/gtk.immodules.temp $TARGET/etc/gtk-2.0/gtk.immodules && | |
| ./gtk-zip.sh && | |
| mv /tmp/${MOD}-${VER}.zip /tmp/$RUNZIP && | |
| mv /tmp/${MOD}-dev-${VER}.zip /tmp/$DEVZIP | |
| ) 2>&1 | tee /devel/src/tml/packaging/$THIS.log | |
| (cd /devel && zip /tmp/$DEVZIP src/tml/packaging/$THIS.{sh,log}) && | |
| manifestify /tmp/$RUNZIP /tmp/$DEVZIP | |
| You should not just copy the above blindly. There are some things in | |
| the script that are very specific to *my* build setup on *my* current | |
| machine. For instance the "latest" command, the "usedev" and | |
| "usemsvs6" shell functions, the /devel/dist folder. The above script | |
| is really just meant for reference, to give an idea. You really need | |
| to understand what things like PKG_CONFIG_PATH are and set them up | |
| properly after installing the dependencies before building GTK+. | |
| As you see above, after running configure, one can just say "make | |
| install", like on Unix. A post-build fix is needed, running | |
| gdk-pixbuf-query-loaders once more to get a correct gdk-pixbuf.loaders | |
| file. | |
| For a 64-bit build you need to remove the gtk/gtk.def file and let it | |
| be regenerated by the makefilery. This is because the 64-bit GTK dll | |
| has a slightly different list of exported function names. This is on | |
| purpose and not a bug. The API is the same at the source level, and | |
| the same #defines of some function names to actually have a _utf8 | |
| suffix is used (just to keep the header simpler). But the | |
| corresponding non-suffixed function to maintain ABI stability are not | |
| needed in the 64-bit case (because there are no older EXEs around that | |
| would require such for ABI stability). | |
| 2) Microsoft's tools | |
| -------------------- | |
| There are VS 2008~2019 solution and project files to build GTK+, which | |
| are maintained by Chun-wei Fan. They should build GTK+ out of the box, | |
| provided that the afore-mentioned dependencies are installed. They will | |
| build GDK with the Win32 backend, GTK+ itself (with GAIL/a11y built in), | |
| the GAIL-Util library and the gtk-demo program. Please also refer to the | |
| README file(s) that reside in win32 on how to enable additional features | |
| that are not enabled by default, such as EGL support via libANGLE, which | |
| emulate the GL/EGL calls using Direct3D 9/11. | |
| Please refer to the following GNOME Live! page for a more detailed ouline | |
| on the process of building the GTK+ stack and its dependencies with Visual | |
| C++: | |
| https://wiki.gnome.org/Projects/GTK+/Win32/MSVCCompilationOfGTKStack | |
| Alternative 1 also generates Microsoft import libraries (.lib), if you | |
| have lib.exe available. It might also work for cross-compilation from | |
| Unix. | |
| I (Tor) use method 1 myself. Hans Breuer has been taking care of the MSVC | |
| makefiles. At times, we disagree a bit about various issues, and for | |
| instance the makefile.msc files might not produce identically named | |
| DLLs and import libraries as the "autoconfiscated" makefiles and | |
| libtool do. If this bothers you, you will have to fix the makefiles. | |
| If desiring to build binaries for ARM64 (aarch64), one needs to use the | |
| Visual Studio 2017 or 2019 solution files, or use Meson with a | |
| cross-compilation file, with a Windows 10 SDK that supports ARM64 | |
| builds. At this point, building the introspection files is not supported | |
| for ARM64 builds, and you will need a Python interpreter and | |
| glib-compile-resources binaries that run on the build machine. For Visual Studio | |
| 2017 ARM64 builds, do also check the Directory.Build.props file in $(srcroot)/win32/vs15 | |
| indicates a Windows 10 SDK version that supports ARM64 builds exists on the build machine. | |
| For building ARM64 binaries with the Visual Studio projects, prior to the build, | |
| you may need to update gtk3-gen-srcs.props to pass in the variables GLIB_MKENUMS, | |
| GLIB_GENMARSHAL, GDBUS_CODEGEN and/or GLIB_COMPILE_RESOURCES in the nmake command line | |
| indicated by <GenerateRequiredSourcesBase> so that they point to the glib-mkenums, | |
| glib-genmarshal, gdbus-codegen and glib-compile-resources that will run on the build | |
| machine. You may also need to update gtk3-version-paths.props to update PythonDir to | |
| the installation of the Python interpreter that will run on the build machine. To carry | |
| out the actual build using the solution files, use the "Configuration Manager" to add the | |
| ARM64 build configs by copying the settings from the x64 configs, and then build the solution. | |
| The build instructions for such builds otherwise follow the standard Win32 (x86) and | |
| x64 builds, but you need to ensure that you have ARM64 builds of the various dependencies. | |
| 3) Using Meson (for Visual Studio and MinGW builds) | |
| --- | |
| Meson can now be used to build GTK+-3.x with either MinGW or Visual Studio. | |
| You will need the following items in addition to all the dependencies | |
| listed above: | |
| - Python 3.5 or later | |
| - Meson build system, 0.48.0 or later | |
| - Ninja (if not using the Visual Studio project generator for | |
| Visual Studio 2010, 2015, 2017, 2019) | |
| - CMake (optional, used for dependency searching) | |
| - pkg-config (optional, or some compatible tool, highly recommended) | |
| For all Windows builds, note that unless -Dbuiltin_immodules=no is specified, | |
| the input modules (immodules) are built directly into the GTK DLL. | |
| For building with Meson using Visual Studio, do the following: | |
| Create an empty build directory somewhere that is on the same drive | |
| as the source tree, and launch the Visual Studio command prompt that | |
| matches the build configuration (Visual Studio version and architecture), | |
| and run the following: | |
| - Ensure that both the installation directory of Python and its script | |
| directory is in your PATH, as well as the Ninja, CMake and pkg-config | |
| executables (if used). If a pkg-config compatible drop-in replacement | |
| tool is being used, ensure that PKG_CONFIG is set to point to the | |
| executable of that tool as well. | |
| - For non-GNOME dependencies (such as Cairo and Harfbuzz), where pkg-config | |
| files or CMake files could not be properly located, set INCLUDE and LIB | |
| to ensure that their header files and .lib files can be found respectively. | |
| The DLLs of those dependencies should also be in the PATH during the build | |
| as well, especially if introspection files are to be built. | |
| - For GNOME dependencies, the pkg-config files for those dependencies should | |
| be searchable by pkg-config (or a compatible tool). Verify this by running | |
| $(PKG_CONFIG) --modversion <dependency>. | |
| - Run the following: | |
| meson <path_to_directory_of_this_file> --buildtype=... --prefix=..., | |
| where buildtype can be release, debugoptimized, debug or plain. Please | |
| refer to the Meson documentation for more details. You may also wish to | |
| pass in -Dbroadway_backend=true if building the Broadway GDK backend is | |
| desired, and/or pass in -Dbuiltin_immodules=no to build the immodules as | |
| standalone DLLs that can be loaded by GTK dynamically. For Visual Studio | |
| 2010, 2015, 2017 and 2019 builds, you may pass in --backend=vs to generate | |
| Visual Studio project files to be used to carry out the builds. | |
| If you are building with Visual Studio 2008, note the following items as well: | |
| - For x64 builds, the compiler may hang when building the certain files, due | |
| to optimization issues in the compiler. If this happens, use the Windows | |
| Task Manager and terminate all cl.exe processes, and the build will fail | |
| with the source files that did not finish compiling due to the hang. | |
| Look for them in build.ninja in the build directory, and change their compiler | |
| flag "/O2" to "/O1", and the compilation and linking should proceed normally. | |
| At this time of writing, the following files are known to cause this hang: | |
| gtk\gtkfilechoosernativewin32.c | |
| gtk\gtkfilesystemmodel.c | |
| gtk\gtktextsegment.c | |
| gtk\gtktextbtree.c | |
| gtk\gtkrbtree.c | |
| testsuite\gtk\treemodel.c | |
| testsuite\gtk\textbuffer.c | |
| testsuite\gtk\rbtree.c | |
| testsuite\gtk\icontheme.c | |
| - Upon running install (via "ninja install"), it is likely that | |
| gtk-query-immodules-3.0.exe will fail to run as it cannot find msvcr90.dll or | |
| msvcr90D.dll. You can ignore this if you did not specify -Dbuiltin_immodules=no | |
| when configuring via Meson. If -Dbuiltin_immodules=no is specified, you need to | |
| run the following after embedding the manifests as outlined in the next point: | |
| <gtk_install_prefix>\bin\gtk-query-immodules-3.0.exe > <gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules.cache | |
| - You will need to run the following upon completing install, from the build | |
| directory in the Visual Studio 2008/SDK 6.0 command prompt (third line is not | |
| needed unless -Dbuiltin_immodules=no is specified) so that the built binaries | |
| can run: | |
| for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;2 | |
| for /r %f in (*.exe.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;1 | |
| for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf;2 | |
| - The more modern visual style for the print dialog is not applied for Visual | |
| Studio 2008 builds. Any solutions to this is really appreciated. | |
| Using GTK+ on Win32 | |
| =================== | |
| To use GTK+ on Win32, you also need either one of the above mentioned | |
| compilers. Other compilers might work, but don't count on it. Look for | |
| prebuilt developer packages (DLLs, import libraries, headers) on the | |
| above website. | |
| Multi-threaded use of GTK+ on Win32 | |
| =================================== | |
| Multi-threaded GTK+ programs might work on Windows in special simple | |
| cases, but not in general. Sorry. If you have all GTK+ and GDK calls | |
| in the same thread, it might work. Otherwise, probably not at | |
| all. Possible ways to fix this are being investigated. | |
| Wintab | |
| ====== | |
| The tablet support uses the Wintab API. The Wintab development kit is | |
| no longer required. The wintab.h header file is bundled with GTK+ | |
| sources. Unfortunately it seems that only Wacom tablets come with | |
| support for the Wintab API nowadays. | |
| --Tor Lillqvist <tml@iki.fi>, <tml@novell.com> | |
| --Updated by Fan, Chun-wei <fanc999@yahoo.com.tw> |