Preamble Folders Order Builds freeglut OpenAL alut PLIB zlib pthreads OpenSceneGraph OpenThreads Producer OSG SimGear FlightGear download end


My first attempt with FlightGear OSG had some success, and some failure. You can read ALL the gory DETAIL on the previous page. This NEW attempt commenced 20 November, 2006. The OSG implementation is still undergoing changes and fixes, so this is still somewhat of a work-in-progress ...

This build, with Microsoft Visual C++ 2005 Express Edition (MSVC8), is using the runtime library 'Multithreaded DLL' (/MD), and 'Multithreaded Debug DLL' (/MDd)! When you create a new project in MSVC8 this is the default, but many prerequisite projects use /MT-/MTd. It is VERY IMPORTANT that the runtime of the prerequisites and the final FlightGear build all use the SAME runtime, or else there will be 'conflicts' in the LINK.

Where possible each of the sources used is the latest update of the cvs or svn source, where possible, or else the latest tarball available. I choose NOT to build in the download, updated folders, but xcopy the source to a new folder. This is mainly because I have the disk space, and, on subsequent updates, I like to review what has been changed before including it. Also this allows me to make local modifications, and be able to do a local diff of the sources.

Folder Structure:

Also, in some cases, when making the xcopy I try to reduce the folder depth, but this entirely depends on the CVS, SVN or tarball original folder. In this case, my 'root' directory is C:/FG/FG0910-7, and in that directory I have the following folder structure -

view of FG0910-7 folder structure

It also shows the current list a prerequisites, and these are the links, (and source indication) - freeglut (cvs), OpenAL (svn), OpenSceneGraph (cvs), OpenThreads (cvs), PLIB (svn), Producer (cvs), pthreads (cvs), SimGear (cvs), zlib (tarball) and OpenGL (NA) ... Although different links have been given for OpenThreads and Producer, these can also be obtained through the OpenSceneGraph link. And although a link has been provided for OpenGL, it is a prerequisite, this comes pre-installed in Windows XP, thus there is no folder for this.

The folders 'bin', 'data', and 'fgfs' are a little special -
bin - is where I run FlightGear.exe from. It contains the required shared libraries (DLLs) to run FG ...
data - is an xcopy of the cvs updated folder. The runtime DATA for FG ...
fgfs - contains an all-in-one solution file, that build ALL the required sources

Build Order:

The order of the build is important, since some of these prerequisites depend on others. Naturally FlightGear MUST be last, since it depends on them all, and generally SimGear should be second last, since it also depends on each of the others. Generally I try to use the static library version of the prerequisite, since this saves the hassle of installing the shared libraries (DLL), but in this build only freeglut, PLIB, SimGear and zlib are STATIC library builds. The others, OpenAL, OpenSceneGraph, OpenThreads, Producer, and pthreads are all shared libraries (DLL).


The Builds:


After xcopying the updated source, loading, and converting freeglut.dsw to solution files it shows two(2) projects - freeglut - DLL, and freeglut_static - static library. Checking the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library I note they presently default to /MT-/MTd, so I change 2 X 2 configuration to /MD-/MDd ... Take care with this change, as mixing Debug and Release can also cause later LINK problems ...

To avoid a VERY UGLY 'depreciation' warning, I also add _CRT_SECURE_NO_DEPRECATE to Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, after adding a ';' separator ...

Generally, I use Build -> Batch Build ... clicking [ Select All ], and [ Build ], or even [ REBUILD ] ... this generates four (4) libraries (LIB) - 2 for the Shared libraries (DLL) and two (2) STATIC libraries, and two (2) Shared Libraries (DLL), which, in this case I may not use -

Shared Libraries (DLL)
Directory of C:\FG\FG0910-7\freeglut\Release
20/11/2006  14:10            32,228 freeglut.lib
20/11/2006  14:10           192,512 freeglut.dll
Directory of C:\FG\FG0910-7\freeglut\Debug
20/11/2006  14:04            32,228 freeglut.lib
20/11/2006  14:10           311,296 freeglut.dll
Static Libraries
Directory of C:\FG\FG0910-7\freeglut\DebugStatic
20/11/2006  14:10         1,111,060 freeglut_static.lib
Directory of C:\FG\FG0910-7\freeglut\ReleaseStatic
20/11/2006  14:10           505,626 freeglut_static.lib
Directory of C:\FG\FG0910-7\freeglut\Release

Ready for the link ...



OpenAL is two(2) separate, but related projects, OpenAL, and alut - BOTH must be built. And you have a choice of using the MSVC6 dsw/dsp build files, and converting them, or the MSVC8 sln/vcproj files ... In this case I choose the MSVC8 files ...


Loading the OpenAL.sln file in MSVC8 shows it consists of four (4) projects, ALc, ALu, OpenAL, and Router. After correcting the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library to my chosen /MD & /MDd (Release & Debug), and opening the Batch Build I note there are sixteen (16) configurations, half of them related to the fast arriving 64-bit ... for the moment, I select all, and de-select the 8 x64 items ...

But on my first batch build, two (2) FAIL - missing an include header - Mmdeviceapi.h ... checking in the alc.cpp source I note this is under a define - HAVE_VISTA_HEADERS! ... the top of apl.cpp shows this is DEFINED unconditionally, just after _CRT_SECURE_NO_DEPRECATE, which I do want defined ... so I glibly comment out the 'have vista', like -


But still find another missing <atlconv.h> header ... In this case I change the line -

#ifndef __MINGW32__


#if ( !defined(__MINGW32__) && !defined( _MSC_VER ))

and it compiles ... This yields 2X2 (4) Shared Libraries (DLLs), and 2x4 (8) libraries, as follows -

Dynamic Link Libraries
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Debug
20/11/2006  14:30           143,360 wrap_oal.dll
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Release
20/11/2006  14:31            86,016 wrap_oal.dll
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Debug
20/11/2006  14:49            77,824 OpenAL32.dll
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Release
21/11/2006  11:17            49,152 OpenAL32.dll
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alc\Debug
20/11/2006  14:30           142,238 ALc.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alc\Release
20/11/2006  14:30            49,814 ALc.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alu\Debug
20/11/2006  14:30            44,190 ALu.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alu\Release
20/11/2006  14:30            11,344 ALu.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Debug
20/11/2006  14:30            20,328 wrap_oal.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Release
20/11/2006  14:31            20,328 wrap_oal.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Debug
20/11/2006  14:49            20,004 OpenAL32.lib
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Release
21/11/2006  11:17            20,004 OpenAL32.lib

This is ready for the LINK, but I must also deal with 'installing' the DLLs in some appropriate place.


There is a alut.dsw, and an alut.sln. I load the MSVC7 'solution' file in MSVC8, and convert. It shows three (3) projects, alut, hello_world, and playfile. I check each of the 6 configurations, but find they have already been set to /MD & /MDd.

My first attempt at running the Batch Build for the 6 configurations shows an interesting error -

c:\fg\fg0910-7\openal\alut\src\alutInternal.h(24) : 
fatal error C1189: #error :  Do not know sized types on this platform

It seems the WIN32 port has not yet reached the cvs source. At the top of the alutInternal.h file, I note a define like -

#include "config.h"

But, as is usual, there is no config.h file! In the *nix would this file is auto-generated by the auto-make tools they use, but in WIN32 we have to manually create one. As you will see later in the FlightGear project, there is no actual config.h, but there is a, and config.h-msvc8 which provides the fairly constant information in WIN32 ... I this case I create a alut/src/config.h, with a single define, HAVE___INT8, and add HAVE_CONFIG_H to the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions ... as follows

// config.h - constants for MSVC compile - geoff mclane - Nov, 2006
#ifndef  __config_h__
#define  __config_h__

#ifndef  HAVE___INT8
#define  HAVE___INT8  1
#endif   // HAVE__INT8


#endif // #ifndef  __config_h__
// eof - config.h

Note at the same time I suppressed the UGLY 'depreciate' warning. Then it can not locate the header alc.h ... but it exists in two (2) locations -

Directory of C:\FG\FG0910-7\OpenAL\include\AL
01/11/2006  16:17             8,124 alc.h
Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Sample\common\include\AL
01/11/2006  16:19             8,124 alc.h

Checking the alut Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories I note it contains -
C:\Program Files\OpenAL 1.1 with EFX SDK\include;..\..\..\include
which I adjust to  -

Like wise for the LINK, I have to adjust the Property Pages -> Configurations Properties -> Linker -> General -> Additional Library Directories to -

Of course, the above adjustments apply to all projects, all configurations 3 x 2 (6) changes ... the use of the $(IntDir) saves changing from Debug to Release in each case ...

This succeeds in producing 2 x 2 DLL/LIB shared library pairs - the LIB is to resolve the 'imports' during the link, and the DLL is needed at runtime -

Directory of C:\FG\FG0910-7\OpenAL\alut\admin\VisualStudioDotNET\alut\Debug
21/11/2006  12:40             5,922 alut.lib
21/11/2006  12:40            73,728 alut.dll
Directory of C:\FG\FG0910-7\OpenAL\alut\admin\VisualStudioDotNET\alut\Release
21/11/2006  12:40             5,922 alut.lib
21/11/2006  12:40            24,576 alut.dll

These are ready for the LINK ...



After doing an xcopy of the update svn source to my work folder, load the PLIB.dsw, and convert there are thirteen (13) projects - fnt, js, net, plib, psl, puAux, pui, pw, sg, sl, ssg, ssgAux and ul. And each of the twelve x 2 (24) - plib is only the glue to bind them all - have to be changed from their default /MT & /MTd to my choice, /MD & /MDd - a BIG click, click, click ... exercise.

I always threaten to write my self a Perl script to do this ;=)) I have started on it, but it is not yet complete. At the same time I add the PESKY - _CRT_SECURE_NO_DEPRECATE to each ... but the Batch Build produces a few errors ...

In ssgSaveAC.cxx, ssgLoadMDL_BGLTexture.cxx and ssgParser.cxx I change the lines -

#ifdef UL_BB
#if (defined( UL_BB ) || defined( UL_MSVC ))

One line in netChat.cxx from

 char* ptr = strstr(data,needle);
 char* ptr = (char *)strstr(data,needle);

There are a few UGLY 'depreciation' and some other warnings, which I ignore. I end up with 2 x 12 (24) static libraries -

Directory of C:\FG\FG0910-7\PLIB
21/11/2006  13:37           233,368 fnt.lib
21/11/2006  13:37           232,222 fnt_d.lib
21/11/2006  13:37            16,542 js.lib
21/11/2006  13:37           156,738 js_d.lib
21/11/2006  13:37            70,450 net.lib
21/11/2006  13:37           267,356 net_d.lib
21/11/2006  13:37           580,674 psl.lib
21/11/2006  13:37           644,230 psl_d.lib
21/11/2006  13:37         1,242,610 puAux.lib
21/11/2006  13:36         1,288,338 puAux_d.lib
21/11/2006  13:36         1,105,292 pui.lib
21/11/2006  13:36         1,130,740 pui_d.lib
21/11/2006  13:36            17,942 pw.lib
21/11/2006  13:36            56,270 pw_d.lib
21/11/2006  13:36           380,856 sg.lib
21/11/2006  13:36           402,364 sg_d.lib
21/11/2006  13:36           544,488 sl.lib
21/11/2006  13:36           507,350 sl_d.lib
21/11/2006  13:35         5,502,922 ssg.lib
21/11/2006  13:34         1,171,810 ssgAux.lib
21/11/2006  13:34         1,214,746 ssgAux_d.lib
21/11/2006  13:36         5,478,616 ssg_d.lib
21/11/2006  13:34           166,388 ul.lib
21/11/2006  13:34           167,964 ul_d.lib

I will not need them ALL for the FlightGear project, but these are ready for the LINK ...



Although there are three (3) solution (SLN) files, I have had some trouble linking with the 'static' library using these, so in this case I use the zlib.dsw, and convert it in MSVC8 ... this has three (3) projects - example, minigzip, and zlib. I only want the static zlib, so unload the other two projects.

The zlib project has 2 x 2 x 2 (8) configurations. 2 x 2 (4) ASM configurations, which requires Microsoft Assembler (ML.EXE) installed. Although I do have this installed, I choose not to use these. The remaining four (4) are Debug and Release of the shared (DLL) and static libraries. In the Batch Build I only select the two static libraries, LIB Debug, and LIB Release. On checking the runtime is already set to /MD and /MDd ... and OF COURSE, I remember to add - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ...

This quickly builds me two (2) STATIC libraries -

Directory of C:\FG\FG0910-7\zlib-1.2.3\projects\visualc6\Win32_LIB_Debug
21/11/2006  13:57           255,574 zlibd.lib
Directory of C:\FG\FG0910-7\zlib-1.2.3\projects\visualc6\Win32_LIB_Release
21/11/2006  13:57           104,542 zlib.lib

These are ready for the LINK ...



In SimGear, simgear/threads/SGThreads.cxx, and in FlightGear ENABLE_THREADS is an OPTION ... SimGear and FlightGear can be built and run WITHOUT using pthreads ... but in this build, I have chosen to include it ... and pthreads should NOT be confused with OpenThreads, which IS a prerequisite of OpenSceneGraph ...

Loading and converting the pthreads.dsw,  there is only one (1) project, with the usual Debug and Release configurations. I check that the Code Generation -> Runtime Library is my desired /MD and /MDd, and add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ... and in Batch Build, [ Select All ] and [ Build ] ...

After the build, I can only find one (1) DLL/LIB pair. This is because the Linker output has been set to the SAME NAME! I change the Debug output to pthreadVC2_d.dll, and the export library to pthreadVC2_d, and then I get 2 x 2 DLL/LIB pairs ...

Directory of C:\FG\FG0910-7\pthreads
21/11/2006  14:49            29,056 pthreadVC2.lib
21/11/2006  14:48            29,386 pthreadVC2_d.lib
21/11/2006  14:49            30,208 pthreadVC2.dll
21/11/2006  14:48            94,208 pthreadVC2_d.dll

Not that I intend to use the Debug version, but it seems to me 'confusing' when all outputs are directed to the same file. These are now ready for the LINK ...



As indicated, OpenSceneGraph has a number of prerequisites - OpenThreads, and Producer, more or less come with OpenSceneGraph, and should be built BEFORE OpenSceneGraph. But if you want to build ALL the plugins of OpenSceneGraph then there are a number of OTHER prerequisites, like jpeg, gdal, gif, tiff, png, ... (the links given are just guesses!) to name a few ...

Also I have the option of trying the latest CVS update, but in this period of transition, if this is used, a number of patches have to be applied. Or one can use the modified source from Olaf/Matias, which seems based on an earlier stable release of OpenSceneGraph ... I opt to try the CVS source first ...


I load and convert the Win2_src/OpenThreads.dsw. This shows there is one project with 2 x 2, 4 configurations - static and shared - I have tried the static, but, like others have indicated, ran into link problems, so am going to use the shared (DLL) configurations ... I check that the Release and Debug configuration are set to runtime /MD and /MDd ...

I add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ...  and in the Batch Build select only Release and Debug, and leave the Release Static and Debug Static unchecked, and [ Build ] ... I am rewarded with 2 x 2 LIB/DLL pairs -

Directory of C:\FG\FG0910-7\OpenThreads\bin\win32
21/11/2006  15:02            18,944 OpenThreadsWin32.dll
21/11/2006  15:02            90,112 OpenThreadsWin32d.dll
Directory of C:\FG\FG0910-7\OpenThreads\lib\win32
21/11/2006  15:02            22,842 OpenThreadsWin32.lib
21/11/2006  15:02            22,908 OpenThreadsWin32d.lib

These are now ready for the LINK ...


While Producer has a MSVC6 Producer.dsw file, I choose to load and convert the MSVC7 Producer.sln file ...

This shows there is one project with 2 x 2, 4 configurations - static and shared - I have tried the static, but, like others have indicated, ran into link problems, so am going to use the shared (DLL) configurations ... I check that the Release and Debug configuration are set to runtime /MD and /MDd ...

I add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ...  and in the Batch Build select only Release and Debug, and leave the Release Static and Debug Static unchecked, and [ Build ] ... I am rewarded with 2 x 2 LIB/DLL pairs - I do not a warning, which I ignore -

Directory of C:\FG\FG0910-7\Producer\bin\win32
21/11/2006  15:13           270,336 Producer.dll
21/11/2006  15:13           753,664 Producerd.dll
Directory of C:\FG\FG0910-7\Producer\lib\win32
21/11/2006  15:13           254,208 Producer.lib
21/11/2006  15:13           254,872 Producerd.lib

These are now ready for the LINK ...


I open and convert the VisualStudio/OpenSceneGraph.dsw. YOW! This shows a massive one hundred and sixty three (163) projects, and as with the above prerequisites there are four (4) configuration, Release, Release Static, Debug, and Debug Static ...

If ever there was a NEED to have a script to check the runtime, and UGLY 'depreciation' define it would be NOW ;=)) But a check of a 'few' projects shows /MD and /MDd, and the PESKY _CRT_SECURE_NO_DEPRECATE  has already been added ... but anyway, I decide it is time to get such a script running ... I need a rest from C++/MSVC, and coding a perl seems a welcome relief ...

OK, did that ;=)) this is a small synopsis in the head of the Perl file - later I will publish the final version - this is a link to an earlier, incomplete effort which only changed to the /MT (or /MTd) runtime ...

#!/Perl -w
# - geoff mclane
# AIM: Given a SOLUTION (SLN) file, extract all projects
# Check and report RUNTIME setting - differentiate Debug/Release / static or not
# IFF $write_changes set, rename the file to .BAK, and write new vcproj file,
# else, just REPORT what would be changed if it was ON.
# IFF $UseMD is set, will adjust to /MD[d], else /MT[d]
# IFF $FixIgnore is set, will remove any IGNORE libraries
# IFF $FixStatic is set, will ALSO adjust those configuration that contain the word STATIC
# IFF $FixPrep1 is set, will ENSURE _CRT_SECURE_NO_DEPRECATE is in Preprocessor defines

I try the Debug configuration build - F7 - it takes quite some time to get through the 163 projects ... of course a number of items build fine, but there are zillions of errors ;=(). I am not so sure I like the new multi-threading of MSVC8 - I did not see this on an earlier version of MSVC8 I tried, or maybe it is only enabled on dual core, or multiprocessors - who knows ...

Now it commences each output line with a number representing the particular project ... but, for example project 6 went on for ages - other project counts of over 100 were showing at the same time ... it seems you must later SORT this output, if you want to read project by project ... the final out of 22,037 lines is -
163>osgWrapper osgUtil - 488 error(s), 262 warning(s)
Build: 52 succeeded, 111 failed, 0 up-to-date, 0 skipped
showing more that more than twice as many FAILED, as succeeded ;=((

A large number of errors are of the form -
103>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRTD.lib(cinitexe.obj)
which is a clear indication of a RUNTIME conflict. Maybe I should let my Perl script change everything to /MD or /MDd? Especially since during this trial I had left the (default) configuration to 'Debug Static' ... I change this to 'Debug' and give it another run - F7 ... that turned around the odds at least -
Build: 141 succeeded, 21 failed, 1 up-to-date, 0 skipped, and there were no LNK2005 conflicts ;=))

Some of the missing include headers (Error C1083) I can fix, like GL/glut.h (osgsimpleviewerGLUT.cpp, osgGLUTsimple.cpp, osgGLUTkeyboardmouse.cpp, ...), zlib.h (ReaderWriterPNG.cpp) - this is just adjusting the Additional Include Directories for those projects ...

But other, like gdal_priv.h (DataSet.cpp, ReaderWriterGDAL.cpp, ...), tiffio.h (ReaderWriterTIFF.cpp), jpeglib.h (ReaderWriterJPEG.cpp), gif_lib.h (ReaderWriterGIF.cpp), ft2build.h (FreeTypeFont.h), dom/domSource.h (domSourceReader.cpp), dae.h (daeReader.h), qtimer.h/QtCore/QTimer (osgsimpleviewerQT3.cpp, osgsimpleviewerQT4.cpp), SDL.h (osgsimpleviewerSDL.cpp), FL/Fl.H (osgsimpleviewerFLTK.cpp), ..., require sources that I do not have ...

Of the twenty one (21) that failed, this is my initial decision tree - EXCLUDE in this case means unload the project, and TRY FIX means exactly that. There is no guarantee that this first fix will not lead to other errors ...

  1. Core osgTerrain, missing 'gdal_priv.h' = EXCLUDE
  2. osgPlugin tiff, missing 'tiffio.h' = EXCLUDE
  3. osgPlugin png, missing 'zlib.h' = TRY FIX
  4. osgPlugin jpeg, missing 'jpeglib.h' = EXCLUDE
  5. osgPlugin gif, missing 'gif_lib.h' = EXCLUDE
  6. osgPlugin gdal, missing 'gdal_priv.h' = EXCLUDE
  7. osgPlugin freetype, missing 'ft2build.h' = EXCLUDE
  8. osgPlugin COLLADA dae, missing 'dae.h' = EXCLUDE
  9. Example osgfadetext, missing 'gdal_i.lib' = EXCLUDE
  10. Example osgsimulation, missing 'gdal_i.lib' = EXCLUDE
  11. Example osgsimpleviewerQT4, missing 'QtCore/QTimer' = EXCLUDE
  12. Example osgsimpleviewerQT3, missing 'qtimer.h' = EXCLUDE
  13. Example osgsimpleviewerSDL, missing 'SDL.h' = EXCLUDE
  14. Example osgsimpleviewerFLTK, missing 'FL/Fl.H' = EXCLUDE
  15. Example osgsimpleviewerGLUT, missing 'GL/glut.h' = TRY FIX
  16. Example osgintersection, missing osgSim::LineOfSight::... = EXCLUDE
  17. Example osgGLUTsimple, missing 'GL/glut.h' = TRY FIX
  18. Example osgGLUTkeyboardmouse, missing 'GL/glut.h' = TRY FIX
  19. Application osgdem, missing 'gdal_iD.lib' = EXCLUDE
  20. osgWrapper osgTerrain, missing 'gdal_priv.h' = EXCLUDE
  21. osgWrapper osgSim, missing HeightAboveTerrain.cpp and LineOfSight.cpp = TRY FIX

So NONE of the five (5) TRY FIX come to the party, but I do succeed in getting 142 built -
Build: 0 succeeded, 0 failed, 142 up-to-date, 0 skipped
and I head out on the Release build - change configuration to Release, and build (F7) ... I timed it, and the compile took about 1/2 an hour ... but I only got 140 -
Build: 140 succeeded, 2 failed, 0 up-to-date, 0 skipped
but it must be something to do with the build ORDER, since another F7 yielded the other two (2) -
Build: 2 succeeded, 0 failed, 140 up-to-date, 0 skipped

I cleaned away the errant Debug Static run, and in bin/Win32 I have 82 x 2 (164) executables, 60 x 2 (120) shared libraries (DLL), and in lib/Win32 13 x 2 libraries (LIB) ... all ready for the LINK ...



I have a perl script,, which reads all the files, and build a SimGear.[DSW/DSP] pair of files, taking configuration from an am2dsp7.cfg file ...

I load and convert the SimGear.DSW file, and despite all my babbling about RUNTIME, I FORGET to check the runtime. Of course, this does NOT show up until you get to linking the static library into FlightGear. Anyway, I subsequently adjust it to /MD and /MDd and build the library again.

Eventually I end up with two (2) STATIC libraries -

Directory of C:\FG0910-5\SimGear\Debug
09/11/2006  18:41        39,554,894 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
09/11/2006  18:38        14,043,870 SimGear.lib

These are now ready for the LINK ...



Using my, I overwrite the FlightGear.[DSW/DSP] files with new ones ...

I load and convert the SimGear.DSW file ... the compile proceeds fine ... lot of warnings, which I ignore ... but again, despite all my babbling about getting RUNTIME right, I end up with lots of errors of the form -

1>msvcprtd.lib(MSVCP80D.dll) : error LNK2005: "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator=(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??4?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z) already defined in acmodel.obj, and
1>MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _sprintf already defined in LIBCMTD.lib(sprintf.obj), which, of course ends with
1>Build log was saved at "file://c:\FG\FG0910-7\FlightGear\Debug\BuildLog.htm"
1>FlightGear - 180 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Some project is NOT RIGHT? Back through them one-by-one - even the unused! ... ALc, ALu, OpenAL, Router, alut, Freeglut, Freeglut static, PLIB - fnt, js, net, psl, puAux, pui, pw, sg, sl, ssg, ssgAux, ul, pthreads, OpenThreads, Producer, OSG - Core - osg, osgDB, osgFX, osgGA, osgIntrospection, osgParticle, osgProducer, osgShadow, osgSim, osgText, osgUtil, osgViewer, osgPlugin - 3dc, 3ds, ac3d, bmp, bsp, dds, directx, dw, dxf, ESRI, fit, geo, hdr, ive, logo, lwo, lws, ... this got too boring, so ran my Perl script, and changed EVERYTHING to MD/MDd, even the 'static' versions, which I am not presently building ... zlib ... AHA, had made an error with ZLIB ...

I tried something I have tried before, and failed - that is using the zlib 'solution' build - but when I link FlightGear top zlibstat.lib, I get a big bunch of UNRESOLVED, obviously ZLIB calls, so I stick to loading and converting the zlib.dsw to MSVC8, and using the static libraries built, namely, zlibd.lib and zlib.lib in their respective $(IntDir) - 'IntDir' is a macro for Debug and Release folders respectively ....

24-11-2006 - Get both DEBUG, and Release version LINKED ...

Directory of C:\FG\FG0910-7\FlightGear\Debug
24/11/2006  11:48        11,788,288 FlightGear.exe
Directory of C:\FG\FG0910-7\FlightGear\Release
24/11/2006  11:58         3,772,416 FlightGear.exe

Now to try to RUN it ... excitement rains ... BUT, how to 'install' the DLLs???


From Microsoft - -
I can see that the FIRST search for a shared library (DLL), is the path of the executable image (binary), so this gives me a chance to put everything in say a 'bin' folder, the main FlightGear EXE and all the prerequisite DLLs ...

This excludes OpenAL - openal32.dll, alut.dll and wrap_oal.dll - from past experience I find these need to be in the 'system' folder - this is the folder returned by GetSystemDirectory(...), which on my system returns -
so this is where I copy these particular files ... this is a batch file I use, which includes a DELETE command ...

This single folder approach works great for the Release configuration ... Debug get more complicated because some shared libraries have the SAME NAME. It is probably better you create a separate sub-folder for that, and to use the debug versions then I always copy all the library build components. Like for pthreads, that would mean -

Directory of C:\FG\FG0910-7\pthreads
21/11/2006  14:49            30,208 pthreadVC2.dll
21/11/2006  14:41               403 pthreadVC2.dll.embed.manifest
21/11/2006  14:41               468 pthreadVC2.dll.embed.manifest.res
21/11/2006  14:49               380 pthreadVC2.dll.intermediate.manifest
21/11/2006  14:49            16,755 pthreadVC2.exp
21/11/2006  14:49            29,056 pthreadVC2.lib
21/11/2006  14:43            40,383
21/11/2006  14:43           486,400 pthreadVC2.pdb

.Actually only the DLL and PDB (Program Data Base)  are really necessary ...

To facilitate this process, I change FlightGear -> Property Pages -> Configuration: Release -> Configuration Properties -> Linker -> General -> Output File to -
and the Debug to
Note the 'd', to denote Debug ... On the same properties page I usually change -> Enable Incremental Linking to 'Default', to avoid some linker warnings ...

If you want to 'discover' which DLLs are missing, then you can try running the Debug version - F5 - ... find and copy that DLL to bin ... but this will miss the needed osg Plugins DLLs ... like  osgdb_ac[d].dll, and osgdb_rgb[d].dll ...

And it is around this time I create the 'data' directory, to hold an xcopy of the recently cvs updated C:/FGCVS/FlightGear/data folder ... add add the command argument
and set the Working Directory to

I'm ready for my first flight ... AND IT FLIES, with sound ...


The frame rate is a dreadful 5 fps with this file full of debug information ... so I only do a short night take off and landing ... only a few minutes ... the first 'external' view, v key-in, is great at night, with all the lights ... I set up a batch file to run from WITHIN the 'bin' directory - with a simple line ...

FlightGear --fg-root=..\data --fog-disable --timeofday=noon

On the first run of flightgear, I usually get the security alert -

Windows NET protection dialog

I nearly always click [ Unblock ] ... I think it is just the PLIB net.lib kicking windows sockets into gear ...

I take off, and begin a climb to about 1500 feet, and do a quiet left 180 turn, to head out into the bay. I head north until I am about within the Oakland, I think it is, approach path, and adjust for a landing ... but regrettably by the time I was down to about 600 feet, BANG, the dread XP dialog -

Windows ABORT dialog

On the next flight I was able to land, taxi, turn, and take off before the BIG BANG occurred ;=))

But the little bit of flying was 'fun' ... saw frame rates 90 fps, even about 115 fps at one time ... happy with everything, except this segfault as it seems to be called in most *nix systems ... this is with the cvs version, updated as of 23 November, 2006 ... GREAT WORK ... keep it FLYING ;=))


Update 22/12/2006: In dynamic cvs/svn sources, this single 'solution' file needs frequent updates to keep track of the changes in the source. The dozen or so, 'simple' steps to use this single 'solution' are as follows -

  1. Update the prerequisite and flightgear sources, and data. I use C:\FGCVS for this. It should contain the following sub-folders - FlightGear/source, FlightGear/data, freeglut, openal, OpenSceneGraph, OpenThreads, plib, Producer, pthreads, SimGear, and zlib-1.2.3.
  2. Download below.
  3. Extract the setup.bat into a folder of your choice. I use C:\FG ... copying the FlightGear/data folder is optional.
  4. Run setup.bat giving a new folder name, say build1 ...
  5. Unzip into this 'build1' folder, overwriting existing vcproj files ...
  6. Unzip, also in this same 'build1' folder.
  7. You may also need to unzip, to 'fix' alc.cpp, unless you have the MS Vista headers installed.
  8. Load build1/fgfs/fgfs.sln into MSVC8, select 'Release' configuration, and build ... some minor fixes may be required ...
  9. Run upd.bat, to copy the builds into the 'bin' folder ...
  10. In bin/openal, run upd.bat, to install the openal DLL, if you do not have these installed.
  11. In the bin folder, use one of the fgr???.bat files to run flightgear ..
  12. ENJOY THE FLIGHT ;=)).
List of FlightGear downloads
Date Download Description Size MD5 Digest
22/12/2006 Full MSVC8 solution set, including fgfs/fgfs.sln to do ALL prerequisites, and EXE as ONE solution, 25 projects


22/12/2006 Full runtime set - EXE and DLLS to run FlightGear in a Windows XP machine.



Note, these downloads are hosted on another server. If clicking on the download link does not start the download, try a Right Mouse Click and choose 'Save Target As...' in the context menu. I have left my first and second attempts below, since most of the explanations are still valid, but are now fully replaced with this updated version ... The runtime zip is much smaller than previous, since it now only contains the Release configuration ...

Update 15/12/2006: This single 'solution' file, and a runtime zip containing all the prerequisite EXE and DLLs worked so well I did it all a second time, hopefully simplifying it even further. Essentially, you should be able to download the runtime zip,, unzip it into a folder, deal with OpenAL if you have not previously installed this, download the FlightGear BASE data, and you should be able to run FlightGear in an XP machine very easily.

Also I have reduced the number of VCPROJ files in the, and separated the files that may need to be changed, and the configuration files into separate zips, within this zip. The zip also contains a README.fgfs which explains all the components ... Note, only the Release and Debug configurations are fully validated.

List of FlightGear downloads
Date Download Description Size MD5 Digest
10/12/2006 Full runtime set - EXE and DLLS to run FlightGear in a Windows XP machine.


15/12/2006 Full MSVC8 solution set, including fgfs/fgfs.sln to do ALL prerequisites, and EXE as ONE solution, 25 projects



Note, these downloads are hosted on another server. I have left my first attempt below, since most of the explanations are still valid, but it is now fully replaced with this updated version ...

This is much easier if you use the SAME directory structure as shown above. The following zips contain -

ZIP - contains ALL the SLN/vcproj files used in preparing this page, including a SPECIAL fgfs.sln, which will build it ALL - when loaded into MSVC8 it will show 24 projects - all the prerequisites, and the final FlightGear.exe ... only the configurations 'Release' and 'Debug' are valid. The other configurations may not function.

ZIP - contains the binary runtime for WIN32. That is the FlightGear.exe, and various shared libraries (DLLs) to execute the application. Theoretically, you could unpack this into a FOLDER, deal with installing the OpenAL DLLs, in the OpenAL folder, then FlightGear.exe should run ... I have not tried FlightGeard.exe ...

Download Description MD5 Digest Full set of solution (MSVC8) build files. The single fgfs.sln will build ALL the prerequisite cvs/svn sources,  then FG MD5 ( = ff2ef9af5423bf10ac24db6692892ead Full runtime binary set - FlightGear.exe, and DLLs. MD5 ( = 1e1debdce2630fdf933c5dbc4b1059b9

USE - As a first step, you should update the cvs/svn source. Create a work folder, and add all the above folders as subdirectories ... xcopy the CVS/SVN sources into each of the folders ... unpack into your work folder, overwriting all the existing *.sln, *.vcproj files ... it will write a simgear/simgear/simgear_config.h,  flightgear/src/include/config.h, and an alut config.h ... load fgfs.sln in MSVC8 ... this should show some 25 projects ...

Select the configuration called 'Release', out of the number of configurations shown - on load it seems to default to 'Debug Static", and this has NOT been tried or tested ... the following image shows the available configurations -

configure MSVC8 to Release (or Debug) ONLY

Select 'Release', and push F7 (build) ... go away and have some coffee ... it takes a while to do its thing ... about 15-20 minutes per configuration on my fast machine ... the final part of the output is -

... just the last few lines, of some 1,569 lines ...
Generating Code...
Embedding manifest...
Build log was saved at "file://c:\FG\FG0910-8\FlightGear\Release\BuildLog.htm"
FlightGear - 0 error(s), 265 warning(s)
========== Build: 25 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

WARNING: This single solution file, as good as it sounds, does NOT always functions as 'advertised'. While I have TRIED to get all the dependencies correct, sometimes I have to choose, and amend Menu -> Tools -> Options ... -> Projects and Solutions -> Build and Run -> maximum number of parallel project build from the default 4 to 1 ... but it should work without this change ...

But remember, all the prerequisite project each has their own 'solution' file, and this can be loaded to build, or rebuild a particular prerequisite ...

USE - Create a work folder ... unzip all, using folder names ... deal with installing the OpenAL shared libraries (DLLs) ... Download, and update the base flightgear data source ... run FlightGear.exe with an appropriate command line, which MUST include --fg-root=<your data folder> at least ...

This zip contains the following files -

Zip file:
  Length   Size  Ratio    Date     Time   Name
 3772416 1500436  61%  24/11/2006  14:32  FlightGear.exe
11788288 3095163  74%  24/11/2006  14:32  FlightGeard.exe
26512080 5353178  80%  24/11/2006  14:32  FlightGeard.ilk
       0       0   0%  25/11/2006  13:21  OpenAL\
   24576   16427  34%  21/11/2006  12:40  OpenAL\alut.dll
   49152   16035  68%  21/11/2006  11:17  OpenAL\OpenAL32.dll
    1014     581  43%  25/11/2006  13:33  OpenAL\README.openal
     473     226  53%  25/11/2006  13:20  OpenAL\upd.bat
     544     241  56%  25/11/2006  13:17  OpenAL\update.mak
   86016   36573  58%  20/11/2006  14:31  OpenAL\wrap_oal.dll
   18944    8756  54%  21/11/2006  15:02  OpenThreadsWin32.dll
   90112   17198  81%  21/11/2006  15:02  OpenThreadsWin32d.dll
 1253376  432122  66%  22/11/2006  17:37  osg.dll
 4272128 1085376  75%  22/11/2006  17:01  osgd.dll
  262144   91205  66%  22/11/2006  17:38  osgDB.dll
 1052672  260765  76%  22/11/2006  17:02  osgDBd.dll
  147456   50551  66%  22/11/2006  17:47  osgdb_ac.dll
  581632  135747  77%  22/11/2006  17:14  osgdb_acd.dll
   22016    9555  57%  22/11/2006  17:38  osgdb_rgb.dll
   69632   17306  76%  25/11/2006  11:52  osgdb_rgbd.dll
  749568  280128  63%  22/11/2006  17:38  osgUtil.dll
 3944448  983953  76%  22/11/2006  17:04  osgUtild.dll
   30208   14929  51%  21/11/2006  14:49  pthreadVC2.dll
    2054     891  57%  25/11/2006  13:59  README.bin
      61      59   4%  24/11/2006  16:34  rfg.bat
      36      36   0%  24/11/2006  16:28  rfghelp.bat
     102      87  15%  25/11/2006  13:38  rfgufo.bat
 ------- -------  ---                     -------
54731148 13407524  76%                          27

The batch file rfghelp.bat will show all the existing commands available to FlightGear; rfg.bat will run the default scenario, and rfgufo.bat will load the UFO aircraft ...



EOP - fgfs-033.htm

Valid HTML 4.01 Transitional