This article refers to both the GNU environment for Windows and the cross-compilation toolchain targeting Windows (for instance under Linux). When necessary, each one will have its own details. However sufficient knowledge of said environment is supposed.

Base system installation

Here we will install the classical toolchain. You should have the following tools:

• GNU make
• GNU g++ (4.x), latest stable being 4.2.1-sjlj
  

In addition, the host system (not necessarily tools targeting Windows) should also provide:

• autoconf (probably >= 2.59) (host version is fine)
• automake (probably >= 1.9)
• pkg-config (necessary for configuration and compilation)
• gettext (only necessary if multi-lingual support is expected)
• Classical core tools: sed, grep, file
• nasm or yasm, as they allow compilation of optimized code in SDL_gfx
• nsis, to create the installer
  

Windows

All of those packages should be available from the MinGW SourceForge download page.
The system should natively have /mingw available

Cross-compilation

Under Ubuntu and Debian, the following packages should be installed:

• mingw32-binutils - Minimalist GNU win32 (cross) binutils
• mingw32-runtime - Minimalist GNU win32 (cross) runtime
• mingw32 - Minimalist GNU win32 (cross) compiler
  

You should then symlink /usr/<target system>, to /mingw, and make the whole subsytem available to the user compiling. One solution is to create a group mingw, add the compiling user (chris here) to that group, and change the ownership of /usr/<target system> to group mingw. This leads to the following commands under Debian or Linux (via sudo or a root shell):
Code BASH :

Note that the changes for chris will only take place once he has logged out and then back in.

chris should then (via a shell script) before compiling do the following:
Code BASH :

The NSIS case under Debian

Due to [url=http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg72233.html]this bug[/url], the setup can't be built under raw nsis Debian install. Lenny ships 2.37 at best, while a fix was only included in 2.42. Fixing this situation seems way too hackish for now.

Additional setup

From time to time, you might need to force the compiler used through the use of the CC and CXX environment values.
You should also create /mingw/bin/i586-mingw32msvc-pkg-config:
Code BASH :

Installing the WarMUX SDK

A file gathering all files needed is available from the WarMUX Windows download page. The current file was made on February 2010.

Building the WarMUX SDK

However, some incompatibilities between hand-compiled libs and the various systems where the SDK was installed may required manually compiling some of the libs. To this end, we will detail all steps necessary to compile this SDK.

Preamble

After all libraries have been installed, it is important to verify the following points:

1. All scripts in /mingw/bin have the proper paths, ie prefix and values return by --libs and --cflags point to the correct location
2. There are no remaining .lib and .la in /mingw/lib
3. All .pc files in /mingw/lib/pkgconfig have the proper paths (same as 1. above)
   

Not that often the --target option is necessary: it instructs that libraries will be used by a mingw-style compiler, therefore with a particular way to decorate functions and create binaries.

SDL

This package requires some modifications:

• Download the mingw devel package from the official SDL download page.
• Edit sdl-config so that:
  Code BASH :

  prefix=/mingw

• Remove lib/libSDL.la, rename SDL.lib as libSDL.a:
  Code BASH :

  rm lib/libSDL.la
  mv SDL.lib libSDL.a

  
  

GnuWin32 libraries

The GnuWin32 houses a number of precompiled binaries which are interesting to us. In particular, WarMUX saves random maps as png and thus has a dependency on libpng. It turns that the one used for SDL_image isn't the same, so SDL_image will be recompiled against it. Anyway, here is a list of the libraries needed both as bin and dev packages:

• zlib1
• libpng
• jpeg
• libintl
• libiconv
  

Once this is done, remove any .la files from lib, edit /mingw/bin/libpng*-config so that:Code BASH : and all_libs ends with a quote.

SDL precompiled side libraries

Here's the list of additional libraries to get as devel package:

• SDL_net from the official page
• SDL_ttf from the official page
• SDL_mixer from the official page
  

Beware that those are compiled with Visual Studio, and may cause some incompatibilities as is. In particular, .lib files can sometimes be renamed to their .a equivalent, but in that case segmentation fault with ld was observed on some platform. However, linking can be done directly against the DLL. Therefore, some postprocessing to the files is suggested:
Code BASH :
This will:

• Move SDL_* headers to /mingw/include/SDL
• Remove the incompatible and unnecessary lib files (MSVC libraries and libtool crap)
• Copy the dll to the equivalent library file
• Move dlls to /mingw/bin
  

SDL_image

The devel package hardlinks to dlls not compatible with our environment setting, so it must be recompiled:

• Get the latest tarball from the official page and unpack it
• Edit configure.in and replace string "jpeg.dll" by "jpeg62.dll" and "libpng*.dll" by "libpng3.dll", which are the one provided by the GnuWin32 packages
• Run autogen.sh and then configure:Code BASH :

  sh autogen.sh
  ./configure --target=i586-mingw32msvc --host=i586-mingw32msvc --prefix=/mingw \
  --with-sdl-prefix=/mingw --enable-shared --disable-static --disable-sdltest

• Verify that configure outputs:
  Code :
  -- dynamic libjpeg -> jpeg62.dll
-- dynamic libpng -> libpng3.dll
• Do the classical make && make install
  

SDL_gfx

There are no precompiled library, so we'll have to compile it ourselves:

• Go the official page and get the latest tarball
• Unpack it and run configure:
  Code BASH :

  ./configure --target=i586-mingw32msvc --host=i586-mingw32msvc --prefix=/mingw \
  --with-sdl-prefix=/mingw --enable-mmx --enable-static --disable-shared --disable-sdltest

• Run the classical make && make install
  

fribidi

One should use the fribidi2 library as it supports much better some RTL languages. Therefore:

• Get the latest tarball from the official page
• Unpack it and run configure (avoiding the native local and incompatible glib) :
  Code BASH :

  ./configure --target=i586-mingw32msvc --host=i586-mingw32msvc \
  --prefix=/mingw --with-glib=no --enable-static --disable-shared

• Edit bin/fribidi-benchmark.c so that utime function (it is only used in a test program) looks like:
  Code C :

  static double utime(void) { return 0.1 }

• Run the classical make && make install
• Because fribidi assume Windows library should always be dynamic, we'll have to force it to be static. Therefore edit /mingw/include/fribidi/fribidi-config.h and add the following line near the end:
  Code C :

  #define FRIBIDI_ENTRY         /* empty */

  
  

curl

I have chosen to use a SSL-less devel mingw package, which unfortunately dates back a lot. The mingw part is important because it provides additional required files (such as bin/curl-config or lib/pkgconfig/fribidi.pc) compared to the MSVC version. So:

• Head to the official download page, possibly modify the selected item in the dropdown list to get what you actually want, though as mentioned the mingw version is selected.
• Unpack it to /mingw
• Edit /mingw/bin/curl-config so that prefix points to /mingw and in particular the return strings using --cflags contain -DCURL_STATICLIB:
  Code BASH :

  prefix=/mingw
  [...]
  echo "-I${prefix}/include -DCURL_STATICLIB"

  
  

libxml2

This one is a tough beast. One computer failed to compile it (blame libtool I guess) while it went flawlessly with another. Anyway, the official Win32 devel package is built using MSVC and is notoriously incompatible with MinGW, so it'll have to be compiled manually. Therefore:

• Grab some source tarball of a version you'd like from the official download folder.
• We need very little from libxml2 so we are going to deactivate a whole lot of things:
  Code BASH :

  ./configure --target=i586-mingw32msvc --host=i586-mingw32msvc --prefix=/mingw \
  --with-zlib=/mingw --enable-static --disable-shared --disable-ipv6 --without-python \
  --without-debug --without-ftp --without-http --without-threads --without-schematron \
  --without-docbook --without-c14n --without-catalog --without-history \
  --without-readline --without-modules --enable-rebuild-docs=no

• Run the usual make
• If it fails, rune make install -k and then verify what was copied. In particular, libxml2.a is often in hidden subfolder .libs/
  

WarMUX itself

At this point, link failures due to missing symbols from the above libraries are usually a bad post-processing of the files or a bad configuration and/or environment when hand-compiling some libraries. In particular, failures due to forgetting the --target were observed.

configure

configure succeeded using the following command-line:
Code BASH :
You may however have to add --build and set manually CC and CXX.

Setting the following flags failed without enough evidence to fix the behavior:

• --with-libcurl strangely fails, probably due to an outdated build/m4/libcurl.m4
• --with-sdl-gfx-prefix causes strange errors
  

Creating setup

It uses nsis through a custom script generated at configure time. Although it is invokable directly, type make install in WarMUX root folder is the preferred way. You should find in build/win32_setup the installer executable, usually named WarMUX-Setup-<version>.exe