You will need to get the GLib, Cairo, Pango, ATK, and GTK+ developer packages to build against GTK+. To run GTK+ programs you will also need the libpng and zlib packages, and if your code uses gettext for internationalization and/or you want GTK+ internationalization, the gettext package.
The packages here are for people who develop software that uses GTK+. This page is not intended directly for end-users. It is expected that people who build installers for GTK+ applications for Windows bundle GTK+ with them.
You are welcome to redistribute GTK+ binaries, including applications that bundle them, on other web sites, CD-ROM, and other media. You don't have to ask for permission. That's one of the points of Free Software. One important thing that the GNU licenses require is that you must also redistribute the source code. This usually means at least the gettext, GLib, GTK+, Pango and ATK sources.
What toolchain to use?
The most natural toolchain to use together with these packages is the GNU compiler and other utilities. When targeting Windows, that combination is known as MinGW. Support for 64-bit Windows is not yet available from the official MinGW project. There is a separate porting effort for 64-bit Windows called mingw-w64. These packages have been built using that compiler, cross-compiling from 32-bit Windows.
It might be possible to use these packages also with Microsoft's compiler. Unlike the 32-bit versions, that has not been actually tested, though. The DLLs here use the msvcrt.dll runtime library.
There are 3 types of download options below. Binaries provide only the DLLs and other files used you will need to run your GTK+-using application. Dev packages provide include files, import libraries, documentation and additional tools, and also for reference the script used to build the component in question. In case patches have been applied to the upstream sources before building, these are inline in the build script. Source packages provide the source code for the component in question. In most cases, this is simply the pristine upstream source release tarball, possibly copied to the same server as the binaries to satisfy the license.
If you want to repackage the necessary runtime files together with your application into an installer, you can choose to leave out for instance message catalogs for languages that your application isn't localised to anyway.
GTK+ 3.6.4 is the current maintained version.
If you find choosing, downloading and unpacking the individual zip archives below a chore, there is an all-in-one bundle of the GTK+ stack including 3rd-party dependencies. The bundle contains both binaries and a lot of developer files, many of which are relatively irrelevant. If you intend to redistribute the GTK+ run-time, you can use this content list to figure out which files you can leave out yourself. A new bundle will ideally be provided here whenever one of the member packages has been updated.
GTK+ individual packages
Required third party dependencies
The run-time packages here are required by the GTK+ stack.
Other third party software
These packages are not needed to run software that uses just GTK+, or to develop such software. These packages are used when building and running more complex applications.
GTK+ 2.22 is the current maintained version.
If you find choosing, downloading and unpacking the individual zip archives below a chore, there are all-in-one bundles of the GTK+ stack including 3rd-party dependencies, both of GTK+ 2.16 and 2.22. The bundles contain both binaries and a lot of developer files, many of which are relatively irrelevant. If you intend to redistribute the GTK+ run-time, you need to figure out which files you can leave out yourself. A new bundle will ideally be provided here whenever one of the member packages has been updated.
GTK+ individual packages
|GTK+||2.16.6 (old, but in many respects more stable)||Binaries||Dev||Sources|
|GTK+||2.22.1 (current maintained branch)||Binaries||Dev||Sources|
Third Party Dependencies
You won't need all of these packages to just use GTK+ Some of the optional packages are needed for building applications like GIMP on Windows. Required packages are illustrated with .
|win_iconv||20090213||Dev & Sources|
|proxy-libintl||20090911||Binaries & sources|
This is an image file format library used by GTK+, and required.
This is the compression library used by libpng and libtiff, and thus also required.
win_iconv is an implementation of iconv for Windows by Yukihiro Nakadaira that has a much smaller footprint than GNU libiconv. The win_iconv package above includes the header file, static archive library and the source file. This library is linked statically into GLib and thus not needed separately at run-time.
The GNU internationalization library. All of the GTK+ stack uses it, but through proxy-libintl (see below) so it is actually optional at run-time.
This program is useful for Makefiles and configure scripts and extensively used in building software according to the GTK+ and GNOME conventions using autotools. It uses a
database specifying inter-dependencies among software packages. It is used to get the compile and link flags needed when building software using libraries that provide pkg-config data. It requires GLib.
About freetype and fontconfig
These libraries are used by cairo and by Pango, so they are required. They provide an alternative font backend. In a normal GTK+ application on Windows their functionality won't actually be used, though. GIMP is an exception, GIMP's text tool uses freetype and fontconfig APIs.
This is a library required by fontconfig.
proxy-libintl is a very small static library. It acts as a proxy for the the DLL from gettext, loading it dynamically, and failing gracefully. Fallback dummy functions are used if the DLL isn't found. It is a static archive and is linked into the binaries in the GTK+ stack instead of referring directly the gettext DLL. This enables application packagers to leave out the gettext binaries if they don't need or want to support internationalization.
When building DLLs against the proxy-libintl static library and using the GNU linker's auto-export feature (i.e. not using a .def file, and not using __declspec(dllexport)), it is a good idea to pass -Wl,--exclude-libs=libintl.a so that the libintl functions don't get exported from your DLL.