RE: GTK+3 win32/64 build environment

I dug up the license for Microsoft Hyper-V Server. Here it is:

See USE RIGHTS. section 'e' bullet 2. Does compiling gtk mesh with bullet 2? If so, your good to go. If not, 
you do not have a license to do what you are attempting. Looking at it, unless you are running at least one 
vm under it, and you are building the software for the purposes of managing and servicing the virtual machine 
(One might be able to make that argument), I'd guess not. IANAL


From: gtk-devel-list [gtk-devel-list-bounces gnome org] On Behalf Of tarnyko tarnyko net [tarnyko tarnyko net]
Sent: Wednesday, April 10, 2013 3:50 AM
To: gtk-devel-list gnome org
Subject: Re: GTK+3 win32/64 build environment

OK folks.

As the initial contributor of the win32 buildenv, here are my reasons for
preferring a native build instead of cross-compiling from Linux. Sorry if it
is long, but I think explaining things will help.

First, please note that we don't have to buy a Windows license. There is a
*free* (as in free beer) edition of Windows named "Hyper-V Server". It's
stripped-down in terms of GUI, but works well for this purpose.

Here is a link to licensing stuff :

and a screenshot of it running "gtk3-demo" while buildenv is compiling GLib


Short version : cross-compiling GTK+3 is a headaches generator. It's not
easy nor efficient, and hard to maintain.

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.

MinGW under Linux is mostly installed via a package manager ("yum install
mingw32-gcc-c++" on Fedora e.g.). You don't get to choose which version of
the compiler you install. Same thing for the dependencies (libtool, expat,
perl, python...). These versions are likely to change regarding the distro
your are using, and you cannot copy their files from one computer to another
because binaries are compiled dynamically (= depend on this particular box'
libc a.s.o).

That means you depend on a precise distro version.
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.

 - GTK+3 build process sometimes needs to run the binaries it has just
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.

 - 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.

gtk-devel-list mailing list
gtk-devel-list gnome org

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