Re: GTK+3 win32/64 build environment

["Arnel A. Borja" <kyoushuu yahoo com>]

Hello,

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 www.gtk.org 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
  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
fi

$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 
http://ubuntuone.com/5lUbY7YCIkaZWHt6ofJnKB 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.


Regards,
Arnel