Skip to content

Cross Compiling LAG for Windows

bsmaldon edited this page Sep 17, 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...

./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. This prevents undefined references to GdkSpanFunc later, whatever that may be.

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/

If wrap_init.cc appears to be missing, then one of the makefiles can be forced to generate it. Simply run cd gdkglext/src && make ./../gdkmm/gl/wrap_init.cc

The following error should then occur font.cc:20:27: fatal error: gdk/gdkglfont.h: No such file or directory

Again, it can be copied from the host system. cp /usr/include/gtkglext-1.0/gdk/gdkglfont.h $PREFIX/include/gtkglext-1.0/gdk/

Finally, the program will fail to link various gdk_gl_draw_ functions and gdk_gl_font_use_pango_font, likely because of the horrible things that have been done to the library at this point. At the time of writing, I see no alternative than to edit these functions to be dummy functions, which seems to work as LAG doesn't use that particular part of the library. There is a risk, however. It might be wise to implement warnings in each of the crippled functions.

HINT: use_pango_font in font.cc may prove difficult. Replace any instance of Glib::wrap(gdk_gl_use...) with Glib::wrap((PangoFont*)NULL).

Following this, gtkglextmm should build and install.

boost

You may find that your operating system provides a version of boost sufficiently up to date, in which case, you can skip this step, using the provided version instead.

Boost, for whatever reason, uses its own build system. Configuring and building it works differently to LAG or any of the other dependencies. This page has the fundamentals of cross compiling boost explained in a way that seems to work, although you will need to make some changes.

First, when making a user-config.jam file, update the compiler to reflect whatever version of mingw32 you have, and all complementary programs. e.g. :%s/i586-mingw32msvc/i686-w64/g

Then, run the bootstrap and bjam scripts respectively, as detailed in the link. Remember to update the --prefix option to whatever is appropriate.

jemalloc

Configures, builds and installs without problems. LAG can technically survive without this.

lzo

Configures, builds and installs without problems.

Clone this wiki locally