-
Notifications
You must be signed in to change notification settings - Fork 5
Cross Compiling LAG for Windows
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.
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.
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)
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
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 --helpfor 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
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 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.