forked from AuroraMiddleware/gtk
9f1b954fff
This adds a set of instructions, notes and known issues for the Meson builds on Windows, especially Visual Studio.
300 lines
13 KiB
Plaintext
300 lines
13 KiB
Plaintext
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++ 2005 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. The VS 2008 project files and/or VS Makefiles are
|
|
either already available or will be available in the next stable release.
|
|
Unfortunately compiling with Microsoft's compilers versions 2003 or earlier
|
|
is not supported as compiling the latest stable GLib (which *is* required for
|
|
building this GTK+ release) requires features from newer compilers
|
|
and/or Platform SDKs
|
|
|
|
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
|
|
--------------------
|
|
|
|
Use the Microsoft compiler, cl and Make, nmake. Say nmake -f
|
|
makefile.msc in gdk and gtk. Be prepared to manually edit various
|
|
makefile.msc files, and the makefile snippets in build/win32.
|
|
|
|
There are also VS 2008~2017 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 build/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.
|
|
|
|
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>
|