Re: GTK+3 win32/64 build environment

On Wed, 2013-04-10 at 12:50 +0200, tarnyko tarnyko net wrote:
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. 

Thanks!  Personally my primary interest for a while has been in getting
a reliable mingw32 cross build of just GLib up, but I haven't found the

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 : 

Hmmm...but it looks to me like this edition is only designed for
physical deployments, whereas I think we'd really want it virtualized
(both for developers running Linux on their laptops who want to test,
and inside the GNOME infrastructure).  Or does it run in a VM ok?

At least for GNOME servers it'd likely be worth paying for an actually
supported version of Windows so it gets security updates, even if it is
completely firewalled off from the world.

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

There are hybrid approaches here - the most realistic to me is to reuse
a current distribution cross toolchain (e.g. we're not building
mingw-gcc in GNOME), but if we need to update some other dependency, we
could do so.

I guess you're right though, the full "SDK" case does kind of explode
due to the perl/python dependencies.

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. 

That doesn't help us though even if it existed due to the Perl/Python
deps among others.

 - GTK+3 build process sometimes needs to run the binaries it has just 

Now an important part - gobject-introspection as used by the bindings at
the moment requires doing this.  But see:

For instance, it runs "glib-compile-schemas" on its XML files to create the 
"schemas.compiled" catalog. Without it, GTK+ programs won't run. 

The way this is solved for the e.g. GNU/Linux cross case is it's assumed
you have glib-genmarshal on the host.  See:

We can definitely do some of this for Windows, but we have to be careful
about files that are architecture dependent.  For glib-compile-schemas
in particular, variants are host endianness by default.

 - You won't be able to test and Q/A the binaries you just produced.

That's where virtualization comes in.

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. 

Wine admittedly is an insane monstrosity, but some of that is likely

So at a high level...there's quite a bit to figure out.  The SDK problem
is just hard =/

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