I actually got interested in all this windows stuff yesterday (no, I
can't explain why), and played around with getting it built.  Here's
the proof:

  http://plausible.org/andy/fgfs-mingw.zip  [2.3 MB]

It's a MinGW* build, using SDL and OpenAL.  It works, with sound and
video mode switching.  The truly interesting thing to me is that it
was built entirely on a Linux box using a cross compiler.

[* I actually didn't use the MinGW-distributed source code for the
   tools, because it didn't build cleanly on linux.  I used the
   standard GNU distributions of binutils and gcc with --target=mingw32
   instead.  I honestly don't know what the differences are; presumably
   the MinGW version is more recent.]

For libraries where I had only a DLL to link against, I hand-built a
libXXX.a import library using dlltool, which worked really well.  I
ended up using the openal32.dll and alut.dll from the NVidia SDK
(which comes in a linux-accessible .zip, not an .exe), although at my
WinXP installation had the Creative runtime installed (it has a nice
installer).  The installer doesn't include alut.dll, though, so I
include that in the package above; creative ships it as a static
library, while NVidia ships a DLL.

Note that I didn't actually build SDL or OpenAL using the cross
compiler.  I used the binaries and headers available on the web.

The build process wasn't terribly clean, but no huge changes were
required either.  Notable notes:

+ There is no Win32 implementation of the simgear/threads stuff, so
  MinGW (and MSVC) builds cannot use threads.  Cygwin can of course
  use the POSIX thread API.  There were a few configuration bugs here
  (#define ENABLE_THREADS 0 ... followed by ... #ifdef ENABLE_THREADS)
  that I had to hack around to turn it off.  We should probably write
  a win32 threading API, since the MSVC folks will want this too and
  it's the only (!) thing tying us to cygwin.dll right now.

+ The GNU libstdc++ and MinGW Win32 headers don't interact nicely in
  some cases.  I found a case where a min() macro caused errors when
  windows.h was included between two C++ headers, but not when it came
  first or last.  There was some similar madness in getting snprintf()
  and isnan() to be detected properly.

+ Interestingly, the infamous _snprintf and _isnan win32 names are a
  non-issue with current mingw32 runtimes, both versions appear in the
  libraries.  The macro tricks I found in simgear/compiler.h (#define
  isnan _isnan, etc...) actually did more harm than good by confusing
  the C++ headers.

+ I didn't try to get glut working, so some auxilliary stuff didn't
  compile.  I hacked around some configure issues and at the resulting
  Makefiles to plug some gaps, too.

I'll try to repeat the deed today, and check in the source code
changes where needed.  Likewise, I'll package up "SDK" versions of the
OpenAL and SDL libraries and/or write instructions so the windows
folks can build against them.  If I'm feeling lucky, I might try to
fix up the configure scripts to handle this stuff better.


Flightgear-devel mailing list

Reply via email to