Re: GTK+3 win32/64 build environment


On Thursday, 11 April, 2013 08:52 PM, tarnyko tarnyko net wrote:
Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain.

I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows.

Agreed, it's a lot faster. Just harder ;-).
Usually the harder part is only in the GTK+ package, which includes some tools that it also uses during compilation. In the other packages, especially libraries, it-just-works, since Autoconf will do the stuff for you and most packages don't need porting anyway since they use GLib (and the developers of GLib and GTK+ are always working to ensure that cross-compilation and native compilation with Visual Studio works, so you don't need to worry much about it). In my my computer, I only run "./install glib-2.36.0" then I will get GLib after some minutes.

For me, native compilation with MinGW is a lot harder than cross-compilation apart from the speed, since your distribution will provide most of the stuff you need (cross-compiler, libtool, autoconf, intltool, ...), they are up-to-date (OBS have the latest cross-compilers - GCC 4.8.0, while MinGW has 4.7.2; distros usually have the latest autotools, intltool, etc.). In MinGW in Windows, we have to look for things ourselves (intltool is in the GNOME FTP site, compilers in MinGW, etc.). Also, MinGW in Windows uses its own (older) versions of make, which sometimes have problems with sh and other stuff - I always get the headache when some packages will compile for infinity, trying to rebuild itself until the world ends :D (or you kill them using the task manager).

The hard part in maintaining is usually checking if the packages are in their latest versions. And sometimes some releases of packages have bugs in Windows (for example, I have some problems with pixman-0.28.2, though I don't think the latest version is required anyway)

Long version with individual points for techs :
- MinGW/GCC for Windows is a standalone compiling environment : basically, you just drop all files in a directory, and it will work, regardless of the OS version you are using. That's because most of the base utils and libraries are compiled statically.

Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in have most of libraries compiled dynamically.

I was mostly speaking about MinGW core binaries (the compiler, linker, etc). ldd shows that the compilers refers to the current libc on Debian for instance. Could work though, but needs some trial-and-error.
You don't need to worry about them anyway, since Ubuntu, Fedora and OpenSUSE will provide them for you (other distros also have them). Let the distros themselves worry about their own tools.

The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python.

Because it doesn't work with newer Python (2.7 and >). I think GLib needs it ; could be patched around, have to check.
I could cross-compile GLib with Python 2.6 without any patches. I don't think GLib requires it, though if you are planning to cross-compile gobject-introspection, you will need (though as far as I know, it only requires Python 2.5).

That means you depend on a precise distro version.

I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems.
Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time.

Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers.
- GTK+3 build process sometimes needs to run the binaries it has just generated. For instance, it runs "glib-compile-schemas" on its XML files to create the "schemas.compiled" catalog. Without it, GTK+ programs won't run. You cannot obviously run Win binaries under Linux -and using wine is not an option here. The only way is to generate, at the same time, the Linux version of the same binary ; that is to say, generate the stack *twice*. One time you obtain "glib-compile-schemas" for Linux, put it safe somewhere, then later during the Windows build you tell it to use *this* particular binary at this particular point. Ugly patches. Or you let the end-user do this, which is not user-friendly.

OBS uses the native tools that come with the build system while cross-compiling the packages. Package mingw32-glib2, while being built by OBS, uses the tools from the glib2* packages (which the build system will already have by default). This way gschemas.compiled is only needed before running applications, since the build system will use its native tools.

So if understand what you explain correctly, it does exactyly what I previously explained (compile the stack once Linux-natively, then cross-compile using some tools from the previous build). It works, I just find it very heavy as it needs some patches. BTW last time I checked gschemas.compiled wasn't provided by OBS.
The distros will usually build the Linux-native tools for you (I recommend to use rolling release of OpenSUSE which have the latest versions, or just use OBS). And gschemas.compiled isn't supposed to be packaged anyway, since it will differ to every computer (depending on what schemas you have installed). You should create this yourself and update it when you install new packages that uses GSettings (apt-get and rpm does it for you in Linux, unless you compiled the package yourself).

- You won't be able to test and Q/A the binaries you just produced.
Wine cannot be used because it's not reliable with GTK+3 ; last time I tried under Debian, fonts were disproportional and pictures sometimes stripped. You have to run them on a native Windows OS. I think I have covered the most important points ; opinions and arguments are welcome. I'm sometimes available on IRC channel for discussions, too.

I use GTK+ 3 in Wine. Just install gnome-themes-standard (actually, compile first since it is not in OBS), then set Adwaita as theme. The default theme sucks in Wine (and sometimes in Windows too, so I use Adwaita in my installers). The problem with the pictures is probably related to the loading of gdk-pixbuf loaders. Probably the loaders cache is not created yet.

You might be right. I'm pretty sure I generated the caches, but the fact libraries were installed in wine's strange prefix ($HOME/.wine) and that I ran the commands directly, may have been the cause of these errors. Have to check again.
I run it this way:

# Register GDK-Pixbuf loaders
if [ -f ${prefix}/bin/gdk-pixbuf-query-loaders.exe ]; then
  echo "********** Registering GDK-Pixbuf Loaders **********"

  # Remove absolute path
  wine ${prefix}/bin/gdk-pixbuf-query-loaders.exe | \
    sed s_Z:$prefix/__g | \
    sed s_Z:`echo $prefix | sed 's_/_\\\\\\\\_g'`/__g \
    > ${prefix}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache

$prefix is /mingw/win32 or /mingw/win64 in my machine (root of MinGW). The sed commands remove the absolute paths.

If you're interested, there is a copy of my scripts in but they don't have enough instructions (the README file is for building Anjuta) and the scripts are messy.

I'm really amazed at your work, because based on my experience, compiling the GTK+ stack using native MinGW in Windows is very hard. I also tried doing what you're currently doing, but ever since I found out about cross-compilation, I never went back to native builds for Windows, though I'm currently working on it again because of Anjuta.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]