bugLordsAWar! - Bugs: bug #26820, Compiling on Windows


bug #26820: Compiling on Windows

Submitted by:  Frans de Jonge <frenzie>
Submitted on:  Tue 16 Jun 2009 05:32:37 PM UTC  
Category: building/compilationSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Fri 03 Jul 2015 07:58:07 PM UTC, comment #24:

We now have a windows version. We don't compile on windows, instead we use mingw to cross-compile for windows.

Ben Asselstine <benasselstine>
Project Administrator
Sat 12 Jul 2014 02:22:33 PM UTC, comment #23:


Many people haven't made the jump away from windows yet.

gstreamermm (e.g. the c++ bindings to gstreamer) is not available as a mingw64 library, but gstreamer (the C library) is.

So migrating from gstreamermm to gstreamer would definitely help in getting LordsAWar onto windows.

yeah it's pretty much in the realm of "theoretically compilable". I'm sure there are lots of bugs waiting though.

Ben Asselstine <benasselstine>
Project Administrator
Sat 12 Jul 2014 02:05:24 PM UTC, comment #22:

And I stopped using Windows in the meantime. :)

If gstreamer is only for audio, I suppose theoretically that means it should be compilable and runnable.

Frans de Jonge <frenzie>
Project Member
Fri 11 Jul 2014 03:43:43 PM UTC, comment #21:

The dependencies for lordsawar have changed.
SDL was replaced with cairo, and libtar was replaced with libarchive.

The only dependency that does not have a mingw64 library is gstreamermm.

Getting lordsawar to compile on windows is a lot closer now.

Making a windows installer for it is still extra work though.

Ben Asselstine <benasselstine>
Project Administrator
Sun 24 Apr 2011 11:56:54 AM UTC, comment #20:

Did the guy ever respond? Now that I've got a little free time due to Easter I'm finally pulling the latest trunk from SVN again and I figured I'd try my hand at some cross-compiling as described on http://mingw-cross-env.nongnu.org/

However, since I (or rather, the very latest PulseAudio, 0.9.22) finally managed to fix the final primary reason I was still using Windows on my desktop, my personal interest in this is only a fraction of what it was when I opened this bug. But I'll be sure to share some ideas and experiences if they seem relevant.

Frans de Jonge <frenzie>
Project Member
Sat 12 Feb 2011 10:52:34 PM UTC, comment #19:

I mailed the libtar guy about getting it compiled on windows.

Ben Asselstine <benasselstine>
Project Administrator
Sun 06 Sep 2009 06:22:58 PM UTC, comment #18:

I'll have to check out how it behaves and such when I'll have time (not for at least another week) - and the computer where I've got all of the stuff set up.

Frans de Jonge <frenzie>
Project Member
Sun 06 Sep 2009 04:40:06 PM UTC, comment #17:

I have removed libglademm as a build dependency.

Ben Asselstine <benasselstine>
Project Administrator
Sun 06 Sep 2009 03:13:36 PM UTC, comment #16:

I have removed the dependency on uuid-dev.

Ben Asselstine <benasselstine>
Project Administrator
Sun 06 Sep 2009 10:54:37 AM UTC, comment #15:

I recently removed all calls to asprintf.

Ben Asselstine <benasselstine>
Project Administrator
Thu 18 Jun 2009 12:19:07 PM UTC, comment #14:

That example compiles just fine for me.


Console output:

It doesn't make a difference if I change the includes to this (like ucompose does)

From what I can tell the Makefile includes sufficient linkers, i.e.

Frans de Jonge <frenzie>
Project Member
Thu 18 Jun 2009 09:44:35 AM UTC, comment #13:

I did some googling, and found this:

Maybe it will help.

Ben Asselstine <benasselstine>
Project Administrator
Thu 18 Jun 2009 02:29:27 AM UTC, comment #12:

I got around the SDL_mixer test in ./configure by editing line 18109 (for me) from


Got ./configure down to

This didn't do anything in regard making it compile more or less, but at least I should probably/hopefully get sound if/when it compiles. ;)

To be sure I changed the following in the Makefile


Not sure if it makes a difference, but I figured I'd better be sure.

I got rid of the WinMain error by putting the following in the /pbm/main.cpp file

I seem to be stuck at the ustring stuff. I don't understand why it isn't working, because glib and gtkmm are functioning just fine. I even have some gtkmm window demo that's showing off all the features (I just noticed it's the same as the GTK window, except the code is much leaner, which I presume is the reason for gtkmm in the first place :P). Here's the full output of make.


Frans de Jonge <frenzie>
Project Member
Wed 17 Jun 2009 11:30:56 PM UTC, comment #11:

For now you can just skip that SDL test.

If you come back to it, perhaps you can find a project that uses sdl + autoconf + mingw32 and use it as an example.

This is inspiring work by the way!

Ben Asselstine <benasselstine>
Project Administrator
Wed 17 Jun 2009 04:36:11 PM UTC, comment #10:

Alright, I'm going to need some help now.

I found that my "last" (read: most recent) error is basically the same as my "first" error.

Namely, config.log tells me the this: http://pastebin.com/d4b772631

Turns out that the SDL stuff was installed fine, but ./configure is messing things up.

I made bla.c, with the following contents, based on the thing used to test for SDL_mixer.

Now if I run the following, you get the same error.

If, however, I run it with the correct arguments (taken from sdl-config --libs), it compiles just fine.

So somehow, ./configure messes this up and I'm not sure what to do about it. I presume that if I fix this mistake in ./configure, it won't show up while making either. Of course that's just a guess, but the lack of using the output from "sdl-config --libs" is bound to lead to this error. See http://www.libsdl.org/faq.php?action=listentries&category=4#58

Frans de Jonge <frenzie>
Project Member
Wed 17 Jun 2009 02:39:03 AM UTC, comment #9:

Here's a patch with all the changes I made in order to make it compile (I'm not saying that it'll work after compilation :P). Here's my most recent compilation error, which I presume must be a bug in one of the GTK files. :/ Anyway, the patch file should identify many problem areas and I even made a few properly looking fixes in some places. I say properly looking because I know Java, PHP and ECMA script (and some basics of some other stuff), so I'm just messing about. ;P

(file #18286)

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 09:09:40 PM UTC, comment #8:

It looks like the asprintf and rand_r stuff are basically deficiencies of my stdio.h, huh. Grmbl.

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 09:07:47 PM UTC, comment #7:

Yeah, I found a replacement asprint.c. I'm now truly stuck on the uuid stuff.

For the sake of compilation I replaced it with

I generated that with uuid.exe.

That was generated with uuid.exe. The compiler told me the variable wasn't even used!

I got another asprintf error, it was easily fixed. I'll quit posting interim patches, I clearly thought I was closer to actual compilation than I was. ;)

Next error

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 08:12:40 PM UTC, comment #6:


That's very nice work so far!!

The min in mingw stands for minimalist. I guess it doesn't have asprintf. It should be pretty easy to find a replacment function. I know gnulib has one.


Ben Asselstine <benasselstine>
Project Administrator
Tue 16 Jun 2009 08:10:13 PM UTC, comment #5:

Alright, got the whole thing to work with the following ./configure

On to the next one :D

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 07:43:50 PM UTC, comment #4:

Correction, apparently expat isn't recognized, akin to SDL_mixer and SDL_image. That's not saying that uuid is no problem, just that it's not what the error is about as I mistakingly assumed.

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 07:24:09 PM UTC, comment #3:

Simply removing gdkx.h from the includes didn't seem to do any damage? However, I'm stuck at uuid.

And regardless of make install -i, the following happens at ./configure.

It seems that the library is a UNIX thing and requires some cross-platform effort. :/ https://issues.apache.org/jira/browse/QPID-1328

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 06:35:32 PM UTC, comment #2:

I fixed my last problem (with /gui/driver.cpp saying sleep is undefined) as per attached patch. It's clearly a tad platform specific. Perhaps http://ubuntuforums.org/showpost.php?p=1735529&postcount=4 is a nice cross-platform solution?

Next error on the list is rather platform specific.

I'll report back with a fix shortly.

(file #18284)

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 06:14:12 PM UTC, comment #1:

I got ucompose to build, see patch. Only the std::basic_ostringstream<wchar_t> os; part is actually relevant. I stole it from Inkscape (http://inkscape.modevia.com/doxygen/html/ucompose_8hpp-source.php) where I noticed the same error in the bug database.

(file #18283)

Frans de Jonge <frenzie>
Project Member
Tue 16 Jun 2009 05:32:37 PM UTC, original submission:

This is part bug report, part guide for self or others interested in compiling LordsAWar! in Windows.


1. Preparation (no bugs here, or at least not related to LAW)
2. Compilation
2.1 The Bug

1. Preparation

Get something to check out SVN, for example http://subversion.tigris.org/ or http://tortoisesvn.net/
For tortoisesvn, right click in any folder you'd like, choose checkout, enter svn://lordsawar.com/lordsawar/ and click ok.
Same basic prinicple for command line SVN, except then you need to use svn checkout svn://lordsawar.com/lordsawar/

As a basic guideline, use ./configure --prefix=/mingw --build=i586-pc-mingw32 for everything.


Seems to require a more recent version of Perl. Perhaps using an older version would fix that. I switched to Strawberry Perl (http://strawberryperl.com/).

libglade & libglademm


make install seems to fail due to some kind of UNIX/Windows binary hiccup. make install tells strip to look for "#INST@3752#" which doesn't exist, while "#INST@3752#.exe" does.

./configure checks in the wrong location, so I used.

mkdir /mingw/include/uuid/
ln -s /mingw/include/uuid.h /mingw/include/uuid/uuid.h

Running ./configure like this should probably work
./configure --disable-sound --disable-rpath --with-uuid=no --prefix=/mingw --build=i586-pc-mingw32
Maybe I should try make install -i. Everything compiled fine...

Do not waste time compiling anything. Just copy the subdirectory boost into /usr/local/include to make ./configure happy later on. I had to make that directory. It also needs to be in /include for more practical purposes. <--- could this be related to the ucompose.hpp stuff? I couldn't really figure out the Boost stuff and that seemed to work... <_<

At the end of the ./configure process, one of the messages is the following, so just to be sure...
Of course you could also just use the .exe file without compiling anything.

You will also need config.guess and config.sub, which you can get from the CVS
of the 'config' project at http://savannah.gnu.org/. The commands to fetch them
$ wget 'http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.guess'
$ wget 'http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.sub'

2. Compilation

Finally managed to resolve everything, ./configure complains about SDL_mixer (even though that should be fine...)

Long story short, I ran ./configure with the following options and everything seemed to be going well.
./configure --disable-sound --disable-rpath --with-uuid=no --prefix=/mingw --build=i586-pc-mingw32

According to the script, ready to run make. Running make produces 4 virtually identical errors that look like this
I fixed these errors by making the deconstructors virtual as per attached patch file. I don't know if that's "good" or not, but it fixes the errors. From what I've read it should only use 4 bytes more memory (http://stackoverflow.com/questions/127426/gnu-compiler-warning-class-has-virtual-functions-but-non-virtual-destructor/127470#127470).

2.1 The bug

Now there's one last obstacle to successful compilation.
Updating the file to 1.0.5 (http://people.iola.dk/olau/compose/) didn't really change anything.
So, I'm stuck. Got any ideas about what might be going on here? :/

Frans de Jonge <frenzie>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #18286:  win32-build.patch added by frenzie (9KiB - application/octet-stream)
file #18285:  driver.patch added by frenzie (471B - application/octet-stream)
file #18284:  driver.cpp added by frenzie (26KiB - application/octet-stream)
file #18283:  ucompose.patch added by frenzie (2KiB - application/octet-stream)
file #18281:  virtual-deconstructor.patch added by frenzie (1KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by benasselstine (Posted a comment)
  • -unavailable- added by frenzie (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 03 Jul 2015 07:58:07 PM UTCbenasselstineOpen/ClosedOpen=>Closed
    Sat 12 Jul 2014 02:22:33 PM UTCbenasselstineCategoryNone=>building/compilation
    Wed 17 Jun 2009 02:39:03 AM UTCfrenzieAttached File-=>Added win32-build.patch, #18286
    Tue 16 Jun 2009 06:36:35 PM UTCfrenzieAttached File-=>Added driver.patch, #18285
    Tue 16 Jun 2009 06:35:32 PM UTCfrenzieAttached File-=>Added driver.cpp, #18284
    Tue 16 Jun 2009 06:14:12 PM UTCfrenzieAttached File-=>Added ucompose.patch, #18283
    Tue 16 Jun 2009 05:32:37 PM UTCfrenzieAttached File-=>Added virtual-deconstructor.patch, #18281

    Back to the top

    Powered by Savane 3.1-cleanup1