Ignorance is not happiness at all

After the moral injection and the union of the Win32 team in #win32 at irc.gimp.org, some more progress have been made already.

I finally got to successfully cross compile Gtk+ with MinGW and all its dependencies (zlib, gettext, libjpeg, libtiff…) using jhbuild. It took me a while to figure out all of the glitches, but I finally come up with a set of modulesets and patches.

It turns out that jpeg and zlib configure/makefile scripts are very tied to the expected unix behavior, and wasn’t very flexible, which make them very hard to build in a jhbuild fashion (automated and configurable). So I’ve been building them statically without noticing it, I finally found a patch for libjpeg from MinGW ports that I used, and had to hardcode the zlib Makefile to make it work.

So I’ve been wasting like a year due to the frustration on not getting this to work due to a sparse knowledge on how dynamic and static linking differences (and the lack of proper messages from autohell). Is there any good documentation to get a good picture about the different kind of linking procedures that exists? I’m still quite confused with .la, .a… and the like.

I’m now storing the modulesets and the patches in a bzr branch within the buildows project at launchpad so I can keep a better track of the changes and we have now a centralized place for the jhbuildrc and the modulesets. If you want to contribute more modulesets (GStreamer, Clutter, WebKit…)  Drop me a line!

Now, If you want to try out this, follow the instructions at the cross compiling wiki page and the brand new Win32 Gtk+ team wiki page.

You just basically has to get jhbuild, place your sample.jhbuildrc in your home directory as .jhbuildrc, and run bin/jhbuild build, you’ll get your windows binaries on ~/gtk-target/. Testers and patchers are welcome!

Advertisements

One thought on “Ignorance is not happiness at all

  1. .la is libtool’s “abstraction” over .a files. I expect it’s so that those sorts of files have the same file name everywhere…
    If you open one, it’s just a text file pointing to the actual relevant file. Same thing with .lo.
    I think it’s meant for cross-platformness, but in practice it just slows down compiling drastically. (Compare a CMake build with an autotools build.) Such abstractions are better done at the Makefile (or equivalent) generation phase anyway.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s