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.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
