Close TOC
-- FlightGear Build MSVC 7.1 --

index

Like all open source build instructions, they can quickly become dated. This was written circa January, 2005, which was with FlightGear source 0.9.8 IIRC.  Go here for a MSVC7.1 November, 2005 build on source 0.9.9, and here for a MSVC7.1 March 2006 build on source 0.9.10. And check out the 'Quick Links' below, or the TOC, if javascript is active, or the index for other, perhaps later builds. Now on with my January, 2005 page ...

After I had completed, a rather long, blurb, about building FlightGear using MSVC6 (Microsoft Visual C/C++ Version 6), I felt the need to try it again with MSVC7 (7.1.3088), so I installed Microsoft Visual Studio .NET 2003 (Pro & .NET Framework 1.1.4322 SP1),  from MSDN Disc 2413.1, plus an online SP update. I had earlier, in 2004, briefly experimented the 'free' Beta 2005 version (8), but you have to be in a 'special' mood, or a need, to be a 'Beta Bunny' ... ;=)) Anyway, this is MSVC7, in an Microsoft XP, Intel P4 3GHz, 512MB RAM, single 120GB HDD, ... system ...

A: Prerequisites

B: FlightGear - FlightGear is an open-source, multi-platform flight simulator [http://flightgear.org/]


A: Building Prerequisites from source ...

GLUT - The Industry's Foundation for High Performance Graphics [http://www.opengl.org/]

From the site, they answer - "Q. What is OpenGL? with A. OpenGL is the most widely adopted, cross-platform standard for 3D rendering and 3D hardware acceleration. The software runtime library ships with all Windows, MacOS, Linux and Unix systems.". You can download, and install a binary release, or you can download, and compile, link, your own, from the source.

Since my current glut.h/glut32.[lib|dll] 'implementation' is sort of 'linked' with my MSVC6, I must make a new provision for MSVC7 ... the headers, like <GL/glut.h>, are in the folder -
C:\Program Files\Microsoft Visual Studio\VC98\Include\GL
I chose to compile-my-own, way back then ... The 'header' question is dealt with when compiling FlightGear below ... I note the 'main' glut.h has 'characteristics' of date=13/12/2000 01:22 AM size=27,670 bytes ... there are others, subsets I think, in other sources, like fltk-2-0-x, ...

You could download GLUT 3.7 from this page, say the glut37data.zip ... you only need the header, glut.h, and the 2 DLL WIN32 files - glut32.lib and glut32.dll - put in the 'right' places ... but this appears an 'older' version, which may have exit troubles, among other things ... but www.xmission.com/~nate/glut.html has/had the 3.7.6 that I use ... or at an 'edu' at  handouts/opengl.html, while it lasts ...there are 'others' ... put 'glut32.dll' into your favourite search engine ... I recently got 'thousands' of hits on yahoo!

top


OpenAL - Cross-Platform 3D Audio [http://www.openal.org/]

As a typical CVS download source command, the OpenAL site gives - (password "guest")
cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository login
cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository co openal
Having set CVSHOME=c:\FGCVS, and changed to the AL directory, enter the first, then the second line ... and 'bingo' a complete source is downloaded. The update command is, after setting the same CVSHOME, change to AL\openal folder, and use > cvs up -dP, keep the source up-to-date ... This also keeps the .cvspass, containing the server and password, for each of the downloads, in one place, %CVSHOME% ...

Searching for the *.sln file, indicates where the MSVC7 starts, as do the *.dsw file, for MSVC6 ... in the folder, c:\FG099\AL\openal\win ... as you know, you can just type > start OpenAL.sln, to load the project(s) directly into MSVC7 ... saves lots of 'clicks' ...

Presently OpenAL exhibits 6 projects ... and I try 'Build', 'Build Solution' (Ctrl+Shift+B) ... the Output shows -
Build: 4 succeeded, 2 failed, 0 skipped
In this case the 'error' is in a post compile event -
Creating library .\Debug/wrap_oal.lib and object .\Debug/wrap_oal.exp
Performing Post-Build Event...
The system cannot find the path specified.
0 file(s) copied.
Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

As you know, MSVC7 keeps a HTML coded log of the compile ... you get a chance to see the ENVIRONMENT variables, and the MANY 'switches', 'options', passed to the compiler ... but in this case I can locate the 'errant' line ... fixing the 'copy' dll line to 'copy\Debug\wrap_oal.dll ..\..\OpenALDemo\wrap_oal.dll', but, take care, another 'Build Solution' click will 'look' as if it all has been done ...

Sometimes, when an error occurs in the post 'build' step of the target, the component may not be deleted, so a re-run will 'appear' complete, without applying the 'fixed' copy post build step ... no 'dependancy' has been created to the copy of the target ... One way around this, is to do a 'Build All', or 'Batch Build Selected, or a 'Clean' first ... In this case I remove all the 'post' build events ... Clean .. Rebuild All ..

I switch to the OpenALDemo project, and 'run' it (F5) ... Since I deleted some 'post' build copying, I expected 'complaints' from the runtime ... missing DLL ... but, nope, the IDE/Debugger sorted it all out, knowing where it built things, and where it got the include libraries, ... and loaded without problem ... It is a nice little console application, to let you test lots of 'sound' factors ...

top


PLIB - Steve's Portable Game Library [http://plib.sourceforge.net/]

Since I use the command line CVS for each of the sources, where available, I just enter the command '> CVS up -dP', in my c:\FGCVS\PLIB folder, and copy the source to c:\FG099\PLIB , open MSVC7, clear away some windows, click menu Open, Project...(Ctrl+Shift+O), and navigate to c:\FG099\PLIB\plib.dsw, select, and open ... then menu, Build Solution (Ctrl+Shift+B), or Build, Batch Build..., and get it all done in one hit ... Select the 'plib' project, or you may only get fnt_d.lib built ...

PLIB copies the results of the compile, a set of WIN32 static libraries, and the appropriate header files, into the PLIB root, a nice tidy touch, made possible by the fact that PLIB adds an '_d' to the Debug version of each library ... These projects are all static WIN32 libraries, so there is nothing to 'run', at the end of the build ... there is, however, a plib_examples.dsw, if you want to see some great image, and model manipulation, animation ... at one time or another I have run most of them, and they are fun, and make you understand scads about the libraries ...

top


Simgear - Simulator Construction Tools [http://simgear.org/]

If you are into 'brevity', then here is a readme.msvc.txt, and readme.msvc6.txt, that 'summarise' the following ... this was written for MSVC6, but functions well in MSVC7, after conversion of the DSW/DSP to SLN/VCPROJ files ...

CVS command line updates require a CVSHOME environment variable, which I put in a batch file, then into the Simgear folder, and > cvs up -dP get me a freshened copy, and I copy it to my work, FG099\SimGear ... with the command 'xcopy /E \FGCVS\SimGear\*.* .' ...

There are at least 2 steps, after the source copy, and that is 1. to rename, or copy the file simgear_config.h.vc5 to simgear_config.h, in folder SimGear\source\SimGear, and 2. decompress the zlib-1.1.4.tar.gz, in folder SimGear\source\src-libs, into a folder of the name zlib-1.1.4 ... or where ever you want to put this widely used zlib.lib, and it headers ...

In MSVS, menu, File, Open, Project..., navigate the FlightGear.dsw, and open ... I usually click 'convert all', and ok, to a few loud, error dialogs ... You should end up with at least the SimGear project ... the 'broken' mklib and zlib projects can be deleted, and zlib put back correctly, by opening zlib.dsp ... right click on 'Solution 'SimGear' (? project(s)), and choose 'Add', 'Existing Project...' and navigate to zlib.dsp, and add ...

I do not usually click on the Build tool, or menu, Build, Build Simgear ... I have configured F7 to do this, through Tools, Customise, Keyboard, search, show Build, select Build.Build Solution, click in 'Press shortcut', and press F7, click Assign ... so here after F7 means Build ...

My first 'error' is not typical - I wrote the above, but failed to actually do item 1. ;=(( It is -
c:\FG099\SimGear\source\simgear\xgl\xgl.h(6) : fatal error C1083: Cannot open include file: 'simgear_config.h': No such file or directory
so I do what I wrote, ... this process is 'automated' in *nix through a /.config script ... onwards, F7 (Build) ...

The next is 'common', until you get all the source folders arranged the way you like them ... it is -
c:\FG099\SimGear\source\simgear\constants.h(44) : fatal error C1083: Cannot open include file: 'plib/sg.h': No such file or directory
This means something is 'wrong' with the include paths ...

Selecting the SimGear project, the Project Properties, opens a rather complicated dialog ... On the left hand 'Configuration Properties' tree ... if not already open ... open the C/C++ pseudo folder, to see the list of 'Categories' ... the 'General' category contains 'Additional Include Directories', which must be 'corrected' ... 

A '.' entry is not usually required, since 'local' headers, those in between inverted command, " ... ", default to the source's directory, and using '.', promotes the 'local' directory, as a 'system' type include, those between less than, greater than, '< ... >', and this would 'seldom' be the case. So, you can remove one if there is one ;=))

The 'error' shows the file being compiled, is 3 levels deep, from the FG099 root, so an additional directory of '..\..\..' is needed ... Apply, Ok to dismiss 'Properties' dialog, and F7, continue ... the next is -
Compiling...
easyxml.cxx
c:\FG099\SimGear\source\simgear\xml\easyxml.cxx(3) : fatal error C1083: Cannot open include file: 'simgear/compiler.h': No such file or directory

Note this is a folder/file include, so the parent of the folder has to be given 'system' search ... now I can see why a local '.' had been added ... I add '.' back to the include list ... ;=)) And one of the windows I close, is the Task list, and end up with a set of tabbed source, with the Output window below ... those who came from MSVC6 will 'recognise' this window layout ...

The next is similar -
c:\FG099\SimGear\source\simgear\sound\sample_openal.hxx(49) : fatal error C1083: Cannot open include file: 'AL/al.h': No such file or directory
which 'reminded' me to download, OpenAL, to c:\FG099\AL ... I  frequently compile open sources in this deal-with-it-as-you-find-it approach ... it is sort of a 'fast-track' learning curve ... I placed it in c:\FG099\AL\openal folder ... add '..\..\AL\openal\include' .. and we should be off again ... F7 (Build)...

At the end of a successful build, sometimes, it is interesting to go back and review the 'warnings', ignored ... in the Task windows, go to 'Next Task', (Ctrl+Shift+F12) ... which I usually assign back to F4, but you then need another key-in to bring up the 'Properties' dialogue, and this is needed a lot, ... maybe Alt+p ;=)) 

Or browse through the BuildLog.htm, in Design view, for some incite full information ... lots, and lots of it ... look at that long list of objects, that make up this set of 'Simulator Construction Tools', SimGear, for short ... a wide, and varied, set of objects ... but, again as a single static WIN32 COFF library, there is nothing to 'run' ... the are some 'test' executables, like props_test.cxx, and others ...

If your MSVC7 has not already created zlib.lib, then it is time to select it, and get it built ... It has no 'dependancies' with any other source, and it can be downloaded separately, directly ... but, thanks to SimGear, it included as a required 'tool' ...

top


B: Building FlightGear

If you want to read a 'brief', less than 500 words, then try readme.msvc.fg.txt, or onwards for a more 'rambling' approach ...

After changing to FGCVS\FlightGear\source, the usual command - cvs up -dP - updates the source ... then I copy it to FG099\FlightGear\source ... As with several 'open' sources, largely maintained on a *nix system, the documentation urges you to do a 'configure' first ... Since we have a 'complete' standard environment, our action in this regard, is to copy, or rename file src\Include\config.h.msvc6.in to config.h ... you can open this file, and 'fix' the 'version' string(s), if desired ...

Opening MSVC7, click File, Open, Project (Ctrl+Shift+O) ... navigate to FG099\FlightGear\source, select, and open FlightGear.dsw, then ok, Open ... I usually click 'Yes To All' in the 'convert' dialogue ... Your 'Solution' 'FlightGear' should have one project, FlightGear ... select this project, then menu Project, Properties ... brings up a 'very full' set of 'pages' ... expanding the C/C++ pseudo-folder, and selecting each in the left list, produces and 'array' of properties to 'play with' ...

We should alway check the Code Generation tag, and ensure the 'Runtime Library' is consistent with the 'configuration' used to build the above 'static' libraries ... I choose, and stick with, 'Muti-threaded', so for the Debug configuration I select 'Multi-threaded Debug (/Mtd)' ... and 'Muti-threaded (/MT)' for the Release (which does not seem as loaded!) ... remember to click 'Apply' when you 'change' things ... ok, ready for my first compile ... I have set F7 to do this, or Build Solution (Ctrl+Shift+B) ...

In the following, what I find now, may not be there, when you download, and do your first build ... FlightGear is a dynamic source ... it can change daily ... so these should be read as 'examples' of the types of 'problems' you will face, probably in any, true, cross-platform, source ... the first part is usually getting all the 'Additional Include Directories' just right, to suit where you put the 'dependant' sources, this time! ... and then some 'common' cross-compiler items, which pop up, from time to time ...

My first 'error' -
c:\FG099\FlightGear\source\src\Traffic\TrafficMgr.cxx(45) : fatal error C1083: Cannot open include file: 'plib/sg.h': No such file or directory
Obviously, something is not right with the 'path' to PLIB ... so I check, change, fix, one of the entries to '..\...', that is back to the FG099 root, from the DSW/DSP location ... I also remove a meta-kit path, ',..\SimGear\metakit-2.4.3\include' - this is no longer needed ... I note there is a '..' entry, thus maybe the dsw/dsp creater, maintainer, uses a 'different' folder structure, or, maybe it is needed, so I leave it ...

The next 'error', -
 c:\FG099\FlightGear\source\src\Traffic\TrafficMgr.cxx(47) : fatal error C1083: Cannot open include file: 'simgear/compiler.h': No such file or directory
This should be 'fixed' with a path '..\..\SimGear\source' ... I note it has a path ' ..\SimGear', obviously aimed at the same 'effect', just with a different, personal, directory structure ... so I amend this one ... then F7 (Build) again ...

The would get an 'error' -
c:\FG099\FlightGear\source\src\Airports\simple.hxx(36) : fatal error C1083: Cannot open include file: 'config.h': No such file or directory
if you did not do the copy/rename given in paragraph one above ... do it now ... continue F7 (Build) ...

The next 'error' could be -
 c:\FG099\SimGear\source\simgear\sound\soundmgr_openal.hxx(48) : fatal error C1083: Cannot open include file: 'AL/al.h': No such file or directory
The DSP maintainer can not 'know' where you loaded OpenAL, so this is a 'common' action ... to provide the 'correct' path ... in my case it is a 'wild' '..\..\AL\openal\include' ...

And you can possibly find -
c:\FG099\SimGear\source\simgear\misc\zfstream.hxx(33) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory
There are just so many places where you can have 'decompressed' zlib.tar.gz ... The project contains '..\SimGear\zlib-1.1.4', which I adjust to my personal '..\..\SimGear\source\src-libs\zlib-1.1.4' ... you can 'see' the difference ;=))

My next 'error' surprised me ... I have been using GLUT for 'years', with my MSVC6, no problem, why then -
c:\FG099\FlightGear\source\src\Main\fg_os.cxx(12) : fatal error C1083: Cannot open include file: 'GL/glut.h': No such file or directory
I begin by checking the BuildLog.htm created by MSVC7 ... it shows the MASSIVE 'system' include path the IDE is using to search for headers -
INCLUDE=C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\include\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\include
Wow, it takes a while, to get your head around that list! ... I just need to copy glut.h, from my MSVC6 path above, to any one of these .NET 2003 paths ... and there it is, a little folder, 'gl', in 'Vc7\PlatformSDK\include' ... so that is where a copy of glut.h is needed ... don't you just 'love' path names today, with spaces, no less ... it really is a good 'typing' exercise, unless you exclusively use the GUI, to do it all ;=)) that is -
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\include\gl
to keep company with GL.h, GLAux.h and GLU.h ... F7 (Build) ...

I have some problems with the prototype of void exit(int) function ... MSVC7 version of stdlib.h has added some ore 'flowery' attributes, to wit -
_CRTIMP __declspec(noreturn) void __cdecl exit(int);
so the 'more-type-safe' compiler flags the prototype in glut.h, as a re-definition, not benign? ... At first, I 'errantly' removed the 'old' definition, from the new copy of glut.h I had made - I changed, added the line -
//# ifndef GLUT_BUILDING_LIB
# if !(defined(GLUT_BUILDING_LIB) || defined(FGFS))
and up new the top drop in the line -
#define GLUT_DISABLE_ATEXIT_HACK 1
to avoid 'exit' needing to be defined ... there is a bit about this in the header ... this just seems an 'update' to deal with a 'newer' - not necessarily better ;=(( - compiler ... I wonder where version 8 will go on this ...

Subsequent events showed that this glut.h modification as wrong! All that was needed was to duplicate the new definitions given in stdlib.h, under the compiler version switch, namely -
#if _MSC_VER >= 1200
_CRTIMP __declspec(noreturn) void __cdecl exit(int);
#else // !#if _MSC_VER >= 1200
extern _CRTIMP void __cdecl exit(int);
#endif // #if _MSC_VER >= 1200 y/n
and there is no re-definition error ...

And, the GLUT32.LIB has to be copied to a MSVC7 'library-include-path' ... for MSVC6, I had placed it in -
C:\Program Files\Microsoft Visual Studio\VC98\Lib
along with its 'mates', GLAUX.LIB and GLU32.LIB, and the 'equivalent' place, for the MSVC7 environment, is -
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib

The compile completes, but the build output 'goes mad', listing the unresolved externals ... that 'suggests' we are 'missing' some of the 'static' libraries, just built above ... ;=)) Look at this near last, output line -
FlightGear - 4001 error(s), 1 warning(s)
Shuff!, only four thousand errors ;=((

In the FlightGear Property Pages, we select, and expand the pseudo Linker folder ... the 'Input' tag, shows 'Additional Dependencies' ... in this case wsock32.lib, the 'old' windows socket library, all by itself - that's no good - we can change to the 'later' sockets, ws2_32.lib, and add those for SimGear, PLIB, AL, zlib ... You start to 'know' them by heart, but a simple PLIB\*_d.lib will show you what there is there ...

While, for example, you may not 'need' all the PLIB libraries, it does no harm to include them ALL ... The linker only 'extracts' those functions used by the application, so there is no 'bloat' from doing this ... And for each 'static' library (set), you must input the appropriate path, in the General tag, 'Additional Library Directories' ... My final, complete 'Additional Dependancies' is -
ws2_32.lib SimGear.lib fnt_d.lib js_d.lib net_d.lib psl_d.lib puAux_d.lib pui_d.lib pw_d.lib sg_d.lib sl_d.lib ssgAux_d.lib ssg_d.lib ul_d.lib zlib.lib ALu.lib ALc.lib ALut.lib OpenAL32.lib

Sometimes, using cvs, sources can be added, subtracted, and for at least a short time, until Am2Dsp is run ... see README.MSVC in SimGear source .. the DSP file can be 'wrong' ... so I tend to always keep my 'adjusted-to-local-environment-DSP' ... and make the necessary source adds, only when required ... usually noted when the linker 'complains' ... ;=))

As stated, not all are actually required ... you can try deleting them one-by-one, to 'see' ... and the rather extensive 'Additional Library Directories' stand at -
..\..\SimGear\source\Debug, ..\..\PLIB,..\..\SimGear\source\src-libs\zlib-1.1.4\Debug, ..\..\AL\openal\win\Alu\Debug,..\..\AL\openal\win\Alut\Debug, ..\..\AL\openal\win\Alc\Debug, ..\..\AL\openal\win\Router\Debug
... quite a mouth full ... but I am REWARDED with -
FlightGear - 0 error(s), 3 warning(s)

It is built, and ready to run ... I add one command line item -
--fg-root=c:\FGCVS\FlightGear\data
and push F5 (run) ...

Oops, I get an 'assert' break ... per the stack frame, in fgAirportDBLoad, using simear::strutils::split(tmp), that is on the Information line of apt.dat.gz ... I put a trap, exit, and restart, so I can trace 'why' the assert? ... ok, if happens using isspace(str[i]) in strutils.cxx,of SimGear ... It croaks on the (c) symbol, and some European chars, like -
- str {"1 9 0 0 TFFC Saint François"}... ok, why isspace if not (str[i] == ' ') ... let's try that ...

I just replace each of the isspace(a), with a sg_isspace(a) ( a == ' ' ) define ... It is simple in the IDE, to load the SimGear project, make 'adjustments', compile, link, then back the FlightGear ... re-link with the new 'static' SimGear ... later fix here ... and give it a burl ...

One of the 'improvements' in MSVC7, over MSVC6, is the down-grading of the following to 'warnings' only - phew -
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCD' conflicts with use of other libs; use /NODEFAULTLIB:library
It always 'bothered' me that the 'linker' could not 'resolve' this conflict ... and now it does ... That places a lot less 'stress' on making sure that the 'configuration' of each of the static libraries agree with the application, into which they are being drawn ... one further improvement would be to 'report' more exactly ... perhaps if you add /VERBOSE as a linker switch, and waded through the rather large BuildLog.htm, then maybe you would 'see' which libraries to 'change' ...

After this 'ignore-hi-bit-characters' fix, I am rewarded with a great Cessna 172 flight ... I take off, circle around to the left, cross the bay, and fly over the stadium, and land in downtown San Fran ... for fun! ... what a great flight simulator ... now I have two build tools, MSVC6, and MSVC7 ...

For flights - see UFO ... or running, debugging FlightGear see here ....

Geoff R. McLane
January, 2005,
Added TOC, Sep, 2006.

msvs

PS: On Wed, 2 Feb 2005, thank you to Vance Souders, for finding a 'fix' for the isspace() assertion, but it seesm now fixed in cvs ... was :-
> I changed the calls to isspace(...) in strutils.cxx to
> ... std::isspace((unsigned char)str[i], std::locale()) ...
> You'll also need to include <locale>.
> -Vance (back)

checked by tidy  Valid HTML 4.01 Transitional