Skip to content

Cross Compiling LAG for Windows

bsmaldon edited this page Sep 14, 2012 · 8 revisions

Overview

I'm documenting this process mostly for myself, since I've already had to re-figure out how to do the whole process once and don't wish to again. But this page should also provide tips to anyone in future attempting to reproduce or update my results. By that time though, this page could be very outdated, so the following is only really an incomprehensive compilation of potential issues and potential fixes.

In retrospect, this may also serve as a general example for cross-compiling unfamiliar programs. Although there is no guarantee of the correctness of the solutions listed here.

Setting Up

If it's not already obvious, cross compilation with the mingw32 toolchain involves grabbing the appropriate mingw32 packages from your OSs repositories, configuring some environment variables for bash, and cross-compiling the dependencies.

mingw32 Packages

Where possible, use the provided packages rather than cross-compiling your own, as this leaves less margin for error and saves time. What packages you will need, however, can be down to trial and error. Some packages are obvious (fedora 17):

  • mingw32-gcc
  • mingw32-gcc-c++
  • mingw32-gtk2
  • mingw32-glib2
  • mingw32-gtkmm24
  • mingw32-pkg-confg (nonobvious)

Environment

You can install dependencies and lag the the operating system's directory for storing all other mingw32 data, but if you don't have root access or don't want to chance causing damage to your system, set up a staging directory for your new builds. mkdir /local1/data/scratch/win32 or mkdir /tmp/win32, for example. You then use this directory as an argument to all of your configure scripts, i.e. ./configure --prefix=/tmp/win32 .... This page will notate this staging directory as $PREFIX.

Then ensure PKG_CONFIG_PATH is set for the terminal you intend to use to compile. It's not recommended to put this in .bashrc, as it will interfere with code built for linux. It needs to include the pkgconfig directory for all of your mingw32 libraries, and the pkgconfig directory for all of your newly installed dependencies. i.e.

export PKG_CONFIG_PATH=/tmp/win32/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig

Compiling Dependencies

Cross compiling dependencies with autotools is typically done by downloading that package as normal, but adding extra options to the configure stage, and running make and make install as normal. Importantly, you will need the --host=i686-w64-mingw32 --build=x86_64-pc-linux, or whatever is appropriate for --build. So your configure option will normally look like:

./configure --prefix=/tmp/win32 --host=i686-w64-mingw32 --build=x86_64-pc-linux Always check the options listed in ./configure --help for each dependency, as they may need to be configured further for cross compiling.

LAG then, as of writing, needs the following libraries available:

  • gtkglext (1.2.0 works)
  • gtkglextmm (1.2.0 works, kind of)
  • boost (~1.50)
  • jemalloc
  • lzo
  • lastools

gtkglext

Reasonably easy to build and install, I used the git checkout (8c13cc). Unfortunately, my build would not produce a correct gdkglenumtypes.h for use in $PREFIX/include/gtkglext-1.0/gdk/gdkglenumtypes.h, which then prevented my compilation of gtkglextmm, and probably anything else useful.

I make sure nothing deprecated is disabled, which it is by default, by removing -D.*_DISABLE_DEPRECATED from gdk/quartz/Makefile.am, as a precaution.

Building from the git repository requires the use of autoreconf -i before configuring.

After installing, copying /usr/include/gtkglext-1.0/gdk/gdkglenumtypes.h to $PREFIX/include/gtkglext-1.0/gdk/gdkglenumtypes.h seems to work.

gtkglextmm

gtkglextmm seems to be particularly hard to cross compile as of writing. I build from the git checkout (bfbd8d).

Firstly, I make sure the library disables nothing deprecated before running autoreconf -i, and I do this by removing any line from any Makefile.am (except for those in the example folder) I see that looks anything like -D.*_DISABLE_DEPRECATED. I recall this fixing some problems, but can no longer say what. Such makefiles are located in gtkglextmm/gtkmm/gl/ and gdkglextmm/gdkmm/gl/.

If the configure script then fails on or around line 16919 on GLIBMM_CHECK_PERL, this is an m4 problem. Since I don't know m4, I just make sure I have the version of perl it asks for, and comment out that one line.

Attempting to build the library will then fail on gdkglext/gdkmm/gl/private/tokens_p.h, for whatever reason. This is down to some kind of script used to generate the headers in that folder, possibly gmmproc, not being run or failing earlier in the build process. This may happen a few times, each time you will need to run /usr/i686-w64-mingw32/sys-root/mingw/lib/glibmm-2.4/proc/gmmproc -I tools/m4 --defs gdkglext/src tokens gdkglext/src gdkglext/gdkmm/gl, replacing tokens with the basename with suffixes stripped for whatever it is you are missing (config for config_p.h, context for context.cc, etc). Try using different perl versions if this fails, gmmproc appears to be in need of maintenance.

The following error may occur at this stage:

drawable.cc:27:29: fatal error: gdk/gdkglshapes.h: No such file or directory

I can't say why gtkglext doesn't install this, there may be a good reason, but for lack of it, gtkglshapes.h can be copied over from the host system.

cp /usr/include/gtkglext-1.0/gdk/gdkglshapes.h $PREFIX/include/gtkglext-1.0/gdk/

Clone this wiki locally