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
