Update 6 June 2006 - MSVC8

index

FlightGear Build Update using Microsoft Visual Studio Express 2005 (MSVC8) on a Windows XP SP2 machine ... First a screen shot, taken from the UFO, hovering over San Francisco ... with no FOG (F8) ;=))

I got it all working, with sound, but with a miserable frame rate of just 1-2 frames per second. HOWEVER, after updating my ATI video drivers from the manufacturers site, I consistently got 50-60 frames per second!

top

Topics:
1. Source updates using CVS or SVN - regular updates
2. Folder Structure - an important first choice
3. pthreads - enable multi-threaded application
4. freeglut - a viable alternative
5. openal - get all the sound you want
6. PLIB - an important addition
7. zlib - be able to 'unzip' on the fly
8. simgear - the important tools
9. flightgear - the best flight simulator there is ;=))
10. Running flightgear - can be easy, or hard ...
11. Batch Files - to make the DLL emplacement easy ...

top

1. CVS (or SVN) Updates:

In this dynamic world some things can change quickly, and seemingly without notice ... Almost each day I would do a CVS (http://ximbiot.com/cvs/cvshome/) update of most of the sources that I 'play' with ... for quite a while, I was getting cvs TIME OUTS on some project ... I had seen this before, and it usually meant the server was busy at that time, but next time I would do the CVS update, it would work, so I tended to ignore this message ... WRONG ;=((

Not this time! ... several of the sources are housed on sourceforge, and it seems sourceforge has changed the servers, or at least the server addressing ... for example, what used to be -

cvs -d:pserver:anonymous@.cvs.sourceforge.net:/cvsroot/plib login

has now become -

cvs -d:pserver:anonymous@plib.cvs.sourceforge.net:/cvsroot/plib login

Small change, but very important for illiterate computers ...

Also, some other sources had CHANGED from using CVS, to using SVN (http://subversion.tigris.org/) - Subversion version control system ... since development of CVS appears to have ceased? ... the checkout and updates are similar, except there is no 'password' step for anonymous checkout, like later versions of CVS ... sources like OpenAL and FGSD (http://sourceforge.net/svn/?group_id=45131), and fgrun have effected this change ...

Of course, if preferred, most sources offer a download of a tar.gz file - like fgsd-0.3.1a.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=45131 ...

Anyway, they are all fixed now, and my daily updates can continue ;=)) Actually I have a BATCH file, that (a) sets the CVSROOT environment variable, and (b) changes into each directory and does a 'cvs up -dP', or in some cases now, 'svn up', and I can sit back and watch the update happen ...

Usually it is all quite quick, except if you have not done it for a while, or there have been some heavy changes in the files ... Also, I made the mistake on my first svn check out of OpenAL, in not adding '/trunk' to the command, and I downloaded ALL modules, tags and branches. The 'trunk' only contains about 3000 files, but the other folders contains some additional 49000 files, so an update was very SLOW ...

While it is not very clear on the OpenAL downloads page - http://www.openal.org/downloads.html - I did just a 'trunk' download of just 2922 files, with the svn command -

svn co http://opensource.creative.com/repos/openal/trunk openal

and after that regular updates were FAST ...

top

2. Folder Structure

The choice of the directory structure to contain FlightGear is IMPORTANT. I have tried several variations ... since I have MANY different builds, I NEVER actually use the CVS (or SVN) download, and updated folders. That is only where I update the sources. This allows me to review the changes before I copy any modified files to my WORK folder ...

It also facilitates doing a LOCAL folder compare, to see what I have changed, and be able to submit such differences back to the community. If you bone up on CVS, and probably SVN, this 'difference' can be done with what is online, but if the online has also changed, then you must know more CVS commands to compare what changes you have made, with an older version on line ... So it is possible to do all the same thing using the CVS/SVN updated sources, but I avoid all that difficulty by making a COPY ...

First I choose a root. In this case it is FG0910-3, since this is the third time I have built FlightGear version 0.9.10 ... That folder will contain the main FlightGear folder, which has sub-directories of source and data ... Now comes the many variations - where to house the 'components' used in the building of FlightGear? Namely SimGear, PLIB, zlib, OpenAL, and if used Freeglut and pthreads ...

The important consideration is that during the building of FlightGear, it will need access to many of the headers of these components during the compile, and the libraries during the link ... MSVC has a default set of 'search paths', which are derived from several important environment variable, or specific setting using the 'options' of MSVC ... But if you wish to separate 'debug' and 'release' builds, then using these 'common' paths is more difficult.

Also some of the components build as STATIC LIBRARIES, and some as DYNAMIC LINK LIBRARIES (DLL). A 'static' library contains all the code within the library module, and during the link that code is extracted, and added to your application. A DLL is where the code is only 'joined' with the application at run time, and the library associated with the DLL is used during the link to resolve what service, functions are IMPORTED at runtime ...

Another consideration is where else are you likely to try to run the FlightGear application. If you want to run it in another computer, or pass it to a friend to try, then 'static' libraries are best, since the only item that needs to be passed is the single EXE file. Of course, using MSVC8 also imbeds Microsoft Framework into the application, so it its a little more than copying the EXE if the second computer does not already have 'Framework' installed ...

Components that are built as a DLL means that DLL must also be copied to the 2nd machine, but still many people 'like' the DLL approach, for whatever reason. Once a DLL is installed, it can of course be used by other application as well, but that 'shared' aspect of a DLL is not very important if the ONLY application to use it is FlightGear ... A DLL can be installed in the SAME folder as the EXE, or usually to ANY PATH enumerated by your environment variable PATH ...

In this update, the folder structure I have chosen is -

FG0910-3\data
        \FlightGear
        \SimGear
        \zlib
        \PLIB
        \openal
        \freeglut
        \pthreads

The build process will proceed from the BOTTOM up ...

top

3. pthreads

After creating this folder, I copy the pthreads source from the CVS download/update folder, to this folder -

> xcopy /E \fgcvs\pthreads\*.* .

This project only has a MSVC6 DSW file to load, pthreads.dsw, and allow MSVC8 to do its conversion. This only offers a DLL build. The items I do change in the project were -

(a) project -> properties -> C/C++ -> Code Generation -> Runtime Library. It defaulted to Multi-threaded DLL (/MD). This I changed to Multi-threaded (/MT) for 'release' and Multi-threaded Debug (/MTd) ...

(b) project -> properties -> C/C++ -> Preprocessor -> Preprocessor Definitions. To avoid and UGLY warning message, I added _CRT_SECURE_NO_DEPRECATE, after a ';', to the list, and

(c) project -> properties -> Linker -> Manifest File -> Generate Manifest. This defaults to 'Yes', and I change it to 'No', since I do not intend to use Microsoft's 'manifest' system ...

(d) project -> properties -> Linker -> General -> Output File. Since I want to SEPARATE a Debug and a Release version, under the Debug configuration I change the output name to .\pthreadsVC2Dbg.dll ... likewise for the 'import library' ...

After building both Debug and Release I have the following available for use -

Directory of C:\FG0910-3\pthreads
05/06/2006 04:24 PM            77,824 pthreadVC2.dll
05/06/2006 04:04 PM           520,192 pthreadVC2Dbg.dll
05/06/2006 04:24 PM            29,056 pthreadVC2.lib
05/06/2006 04:24 PM            29,056 pthreadVC2Dbg.lib

Since, in a DLL case, the 'library' only contains a list of linker headers, that will be used to IMPORT from the dynamically loaded DLL, then the Debug and Release libraries contain the same thing, except the name of the DLL to load. You can see the Debug DLL is much larger, since it contains a lot of debug information ...

Later these DLLs must be 'installed' where FlightGear.exe can find them ...

Addendum: As can be seen below, when I got to building flightgear there was a 'conflict' between the config.h used there, and the config.h used in this project. I decided to rename the pthreads config.h to ptw32_config.h, and this also requires changing the name in pthread.h, although in this build this file is NOT included, since HAVE_CONFIG_H is NOT one of the preprocessor definitions ... maybe it should be, but will leave that to later ...

Now I have some NEW files -
07/06/2006 12:50 PM            77,824 pthreadVC2.dll
05/06/2006 04:04 PM           520,192 pthreadVC2Dbg.dll
07/06/2006 12:50 PM            29,056 pthreadVC2.lib
07/06/2006 12:50 PM            29,056 pthreadVC2Dbg.lib

Initially the linker failed to locate ws2_32.lib, the windows socket library, version 2. Also as mentioned later, I had meantime upgraded to the "Microsoft Platform SDK for Windows Server 2003 R2", and although I had run the utility to 'register' this new path in MSVC8, it did not get into Tools -> Options ... -> Projects and Solutions -> VC++ Directories -> Show directories for: Library files, so I had to MANUALLY add a path to this SDK ...

top

4. freeglut

After creating this folder, I copy the freeglut source from the CVS download/update folder, to this folder, removing one level of 'freeglut' in the process -

> xcopy /E \fgcvs\freeglut\freeglut\*.* .

This project only has a MSVC6 DSW file to load, freeglut.dsw, so I load it and allow MSVC8 to do its conversion. This offers two(2) project, freeglut, a DLL, and freeglut_static, a static library. I choose to 'unload' the freeglut DLL, since as mentioned above, I prefer that all the code in one application, rather than having to install a DLL in the appropriate place ...

As will be usual, I do add _CRT_SECURE_NO_DEPRECATE to project -> properties -> C/C++ -> Preprocessor -> Preprocessor Definitions to avoid the UGLY warning, and do CHECK that the Runtime Library is set to Multi-threaded (/MT), and /MTd for debug ... and build ...

I am rewarded with two(2) static libraries -
Directory of C:\FG0910-3\freeglut\DebugStatic
05/06/2006 04:30 PM 1,072,774 freeglut_static.lib
Directory of C:\FG0910-3\freeglut\ReleaseStatic
05/06/2006 04:30 PM 502,146 freeglut_static.lib

that I will link to later ...

Note the debug version is over twice the size of the release version ...

top

5. openal

Having created the new folder, I copy the SVN updated source to here, with -

> xcopy /E \fgcvs\openal\*.* .

(a) OpenAL.sln

This project already has a MSVC8 solution file, OpenAL.sln, so I load this, and am presented with 4 projects - ALc, ALu, OpenAL32, and Router. It should be noted there is alut.sln file, which will be dealt with later ...

I note ALc and ALu are static libraries, and OpenAL32 and Router are DLL projects. As usual, for each I check the Runtime Library is set to MT and MTd respectively, and note that the debug configuration is set only to MT! And, of course, I set the manifest file to 'No' ...

The first problem I run into is that the project can not locate dsound.h, the header file for Microsoft's DirectX ... I do find that I have an older version in -

C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\
19/06/2002 11:56 AM 110,604 dsound.h

BUT that is an OLDER 2002 version, downloaded for MSVC7 ... so I set about locating, and downloading the 'latest' DirectX SDK from Microsoft ...

I find a download at -
http://www.microsoft.com/downloads/details.aspx
?FamilyId=7AB978B5-5F1A-4F6A-88EB-FC646138BECA&displaylang=en
and proceed to download dxsdk_apr2006.exe, a 390 MB file, that takes nearly 2 hours on my modest broadband connection (256KB) ... I only get a download throughput of about 60KB/sec over this line ... one day I MUST afford myself an 'upgrade' ;=))

After installing this DirectX SDK, I have an include path to the 'latest' dsound.h -

"C:\Program Files\Microsoft DirectX SDK (April 2006)\Include"

I add this path to project OpenAL32 -> properties -> C/C++ -> General -> Additional Include Directories, for both Debug and Release configurations ...

And add - "C:\Program Files\Microsoft Platform SDK\Include\mfc" to find afxres.h to both OpenAl32 and Router -> properties -> Resources -> General -> Additional Include Directories ... and "C:\Program Files\Microsoft Platform SDK\Include\atl" to Router -> properties -> C/C++ -> General -> Additional Include Directories to be able to find atlconv.h ... I also disable all 'Browse' file creation, but this is not important ...

I end up with a nice set of libraries -
Directory of C:\FG0910-3\openal\OpenAL-Windows\Alc\Debug
06/06/2006 02:03 PM           138,902 ALc.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\Alc\Release
06/06/2006 02:07 PM            49,616 ALc.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\Alu\Debug
06/06/2006 02:03 PM            41,848 ALu.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\Alu\Release
06/06/2006 02:07 PM            11,200 ALu.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Debug
06/06/2006 02:03 PM            20,328 wrap_oal.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Release
06/06/2006 02:08 PM            20,328 wrap_oal.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\Router\Debug
06/06/2006 02:07 PM            20,004 OpenAL32.lib
Directory of C:\FG0910-3\openal\OpenAL-Windows\Router\Release
06/06/2006 02:08 PM            20,004 OpenAL32.lib

And some DLLs -
Directory of C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Debug
06/06/2006 02:03 PM           708,608 wrap_oal.dll
Directory of C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Release
06/06/2006 02:08 PM           188,416 wrap_oal.dll
Directory of C:\FG0910-3\openal\OpenAL-Windows\Router\Debug
06/06/2006 02:07 PM           589,824 OpenAL32.dll
Directory of C:\FG0910-3\openal\OpenAL-Windows\Router\Release
06/06/2006 02:08 PM           102,400 OpenAL32.dll

(b) alut.sln

There is a MSVC6 alut.dsw, and alut.sln. This 'solution' file was from MSVC7, but MSVC8 converted it on loading, and showed 3 projects - alut, hello_world, and playfile ... On checking alut -> project -> Properties -> C/C++ -> Code Generation -> Runtime Library, it defaults to MDd and MD - the multi-threaded DLL version. I correct this to my chosen runtime MTd and MT for Debug and Release respectively.

And under alut -> project -> Properties -> Linker -> Manifest File -> Generate Manifest, I switch it to 'No' for Debug and Release. And as usual, add _CRT_SECURE_NO_DEPRECATE to alut -> Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, to remove the NASTY warning ...

These changes could also be applied to the hello_world and playfile projects, but I choose to 'unload' these two 'test' projects, at least for now ...

Under alut -> Project -> Properties -> C/C++ -> General -> Additional Include Directories I note it is pointing to an SDK, and back 3, and into include with -

C:\Program Files\OpenAL 1.1 with EFX SDK\include;..\..\..\include

I change this string to -

..\..\..\..\include;..\..\..\..\include\AL;..\..\..\include;..\..\..\include\AL

but maybe this is OVERKILL ...

Likewise, under alut -> properties -> Linker -> General -> Additional Library Directories, I remove the SDK reference -

C:\Program Files\OpenAL 1.1 with EFX SDK\libs\Win32

and add my path to OpenAl32.lib

"..\..\..\..\OpenAL-Windows\Router\$(OutDir)";

Note the use of the MACRO '$(OutDir)', since this automatically handles the Debug and Release, so the string can be the same in both configurations ...

This produces -
Directory of C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Debug
07/06/2006 02:27 PM           593,920 alut.dll
Directory of C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Release
07/06/2006 02:27 PM           126,976 alut.dll
Directory of C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Debug
07/06/2006 02:27 PM             5,922 alut.lib
Directory of C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Release
07/06/2006 02:27 PM             5,922 alut.lib

Again, I will later have to 'install' these DLLs in a place where FlightGear can load them ... and in the link of flightgear provide paths to these import libraries ...

top

6. PLIB

After creating the folder, I copy the CVS source, using -

xcopy /e c:\fgcvs\plib\*.* .

After loading plib.dsw, and allowing MSVC8 to convert, I see 13 projects ... I change the 'Start Up' project to plib, but this is probably not required since these are all independent static libraries ...

It is necessary to check ALL 12 projects - fnt, js, net, psl, puAux, pui, pw, sg, sl, ssg, ssgAux and ul - properties -> C/C++ -> Code Generation -> Runtime Library, are all set to MTd and MT, Debug and Release, respectively ...

And unless you want to see many UGLY warnings, like -

c:\fg0910-3\plib\src\util\ul.h(551) : warning C4996: 'strcpy' was declared deprecated
c:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(73) : see declaration of 'strcpy'
Message: 'This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'

you have to add _CRT_SECURE_NO_DEPRECATE to properties -> C/C++ -> Preprocessor -> Preprocessor Definitions. I add it to ALL, although this may not be neccessary, and to both Debug and Release configurations ... lots of clicking and pasting ;=))

Unfortunately, this update has some ERROR, as well as the usual list of 'warnings' ... the errors must be fixed, but I usually ignore the warnings ...

The first ERROR is -
------ Build started: Project: pui, Configuration: Debug Win32 ------
Compiling...
puVerticalMenu.cxx
.\puVerticalMenu.cxx(27) : error C2653: 'puVerticalMenu' : is not a class or namespace name
.\puVerticalMenu.cxx(27) : error C2065: 'RTTI_obj' : undeclared identifier
.\puVerticalMenu.cxx(27) : error C2673: 'RTTI_cast' : global functions do not have 'this' pointers
.\puVerticalMenu.cxx(27) : error C2352: 'puGroup::RTTI_cast' : illegal call of non-static member function
c:\fg0910-3\plib\src\pui\pu.h(847) : see declaration of 'puGroup::RTTI_cast'

and more ... all this comes from a macro -

UL_RTTI_DEF1(puVerticalMenu,puGroup)

This in turn invoke another macro -

#define UL_RTTI_DEF1(cls,b1)          \
      UL_RTTI_DEF1_BASE(cls,b1)      \
      UL_RTTI_NO_NEW(cls)

AWK! I even fired up MSVC7, and started again, but the SAME errors popped up ... All I can do is EXCLUDE these files from the build, and hope FlightGear does NOT use any of these components ;=((

PLIB conveniently separates the debug from the release static libraries by adding a '_d' to the debug versions, and copies each of them, together with the PLIB headers all to the root of the PLIB folder ... so after trundling on for a few minutes, I have -

Directory of C:\FG0910-3\plib
06/06/2006 03:45 PM           226,430 fnt.lib
06/06/2006 02:43 PM           225,124 fnt_d.lib
06/06/2006 03:45 PM            15,486 js.lib
06/06/2006 02:42 PM           141,320 js_d.lib
06/06/2006 03:45 PM            69,428 net.lib
06/06/2006 03:39 PM           252,316 net_d.lib
06/06/2006 03:45 PM           552,744 psl.lib
06/06/2006 02:42 PM           611,628 psl_d.lib
06/06/2006 03:44 PM         1,202,014 puAux.lib
06/06/2006 02:42 PM         1,247,730 puAux_d.lib
06/06/2006 03:44 PM         1,166,364 pui.lib
06/06/2006 03:41 PM         1,193,204 pui_d.lib
06/06/2006 03:44 PM            17,744 pw.lib
06/06/2006 02:41 PM            52,578 pw_d.lib
06/06/2006 03:44 PM           369,310 sg.lib
06/06/2006 02:41 PM           391,066 sg_d.lib
06/06/2006 03:44 PM           516,862 sl.lib
06/06/2006 02:41 PM           478,158 sl_d.lib
06/06/2006 03:43 PM         5,285,878 ssg.lib
06/06/2006 03:42 PM         1,135,560 ssgAux.lib
06/06/2006 02:40 PM         1,177,060 ssgAux_d.lib
06/06/2006 03:38 PM         5,239,422 ssg_d.lib
06/06/2006 03:42 PM           152,766 ul.lib
06/06/2006 02:39 PM           154,032 ul_d.lib

Of course, the pui.lib will be quite 'broken' since I excluded about 5 files from the build ... it remains to be seen how that plays out when linking with FlightGear ... maybe I will have to return to try some fixes ...

top

7. zlib

This source does not appear to be available via cvs or svn, but a zlib-1.2.3.tar.gz, or other formats, is downloadable from the home site - http://www.zlib.net/. This file contains the root path zlib-1.2.3, thus only after it is unpacked into a folder of that name can I copy it to my zlib folder with -

>xcopy /e \fgcvs\zlib-1.2.3\*.* .

This source contains not only zlib.dsw for MSVC6, but a zlibvc.sln for MSVC7 and a zlibvc.sln for MSVC8 ... I first try the zlibvc.sln for MSVC8 ... this contains 6 projects - miniunz, minizip, testzlib, testzlibdll, zlibstat and zlibvc ... As stated, my preference is for static libraries, since all the code is imported at build time, rather than through 'installing' and dynamically loading a DLL ... so I choose to 'unload' the other 5 projects, and only build zlibstat ...

Initially I had some difficulty bringing up the property pages, since it seems it was defaulting to a Itanium build ... after fiddling a bit, and ensuring Win32 was the default build, I was able to check that zlibstat was set to MT[d] ...

After the build of Debug and Release, I had -
Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibStatDebug
06/06/2006 05:17 PM 589,976 zlibstat.lib
Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibStatRelease
06/06/2006 05:17 PM 161,830 zlibstat.lib

These are ready for a link ...

top

8. simgear

After creating the simgear folder, I copied the source with -

> xcopy /e \fgcvs\simgear\source\*.* .

Note that I have reduced one level of folders by copying the simgear\source ...

Simgear has a MSVC6 SimGear.dsw, and a MSVC8 simgear.sln file ... naturally I try the simgear.sln file ... it is a single static library project, simgear ... Naturally I check the project -> properties -> C/C++ -> Runtime Library is set to MT and MTd for Release and Debug respectively ... and it already has a good list of properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, namely -

WIN32;_DEBUG;_WINDOWS;HAVE_CONFIG_H;ENABLE_THREADS;_CRT_SECURE_NO_DEPRECATE; _CONST_CORRECT_OVERLOADS;NOMINMAX;_USE_MATH_DEFINES

The important things are that ENABLE_THREADS is there, NOMINMAX, and _USE_MATH_DEFINES ... so I am ready to build immediately ;=)) But first I must fix up the properties -> C/C++ -> General -> Additional Include Directories. It starts with a default of -

../..;../../..;../../Simgear;../../../AL/include;"../../../zlib-1.2.3"; "../../../Pre-built.2/include"

which is not going to suit my folder, and component placement structure ... these are all relative to the simgear.vcproj file in -

C:\FG0910-3\SimGear\projects\VC8

so to deal with each -

../.. - will be back to the simgear root, which is needed for things like <simgear/compiler.h>, <simgear/props/props.h>, ... etc

../../.. - will be out of the simgear folder, and thus give access to things like <plib/sg.h>

../../simgear - will give access to <simgear_config.h>

../../../AL/include - in my particular folder names, and placement, this has to be changed to ../../../openal/include, which is out of the simgear folder, and into the openal folder, and gives access to <AL/al.h> ... and since my alut.h is in C:\FG0910-3\openal\alut\include, I must also add ../../../openal/alut/include for <al/alut.h> ... AND since <al/alut.h> includes <alc.h>, I must also add a direct reference ../../../openal/include/AL

../../../zlib-1.2.3 - in my case this must be changed to just ../../../zlib to give access to <zlib.h>

../../../Pre-build.2/include - in my case this must be changed to ../../../pthreads to find <pthreads.h>

So, I put back the string, in both debug and release -

../..;../../..;../../Simgear;../../../openal/include;../../../openal/alut/include; ../../../openal/include/AL;../../../zlib;../../../pthreads

The first part of the Debug build does another important step - to copy the simgear_config.h.vc5 to simgear_config.h ... there are some 20 plus warnings, but I ignore these ...

I am rewarded with -
Directory of C:\FG0910-3\simgear\projects\VC8\Debug
06/06/2006 06:05 PM 33,520,388 SimGear.lib
Directory of C:\FG0910-3\simgear\projects\VC8\Release
06/06/2006 06:11 PM 22,856,812 SimGear.lib

top

9. flightgear

Finally I reach the last piece in the puzzle. After creating a folder, flightgear, I copy the CVS source with -

>xcopy /e \fgcvs\flightgear\source\*.* .

Note again, I have 'lost' one folder depth in doing this ...

Like simgear, flightgear has both flightgear.dsw (MSVC6), and flightgear.sln (MSVC8) ... Naturally I load flightgear.sln ... here flightgear is strangely split into 2 projects - flightgear, and flightgearlib ... the usual check should be made that the runtime library is set to MTd and MT for debug and release respectively ...

Checking the preprocessor string, it is -

WIN32;_DEBUG;_WINDOWS;ENABLE_THREADS;HAVE_CONFIG_H;_CRT_SECURE_NO_DEPRECATE;_CONST_CORRECT_OVERLOADS;NOMINMAX;FREEGLUT_STATIC

Note it already includes the FREEGLUT_STATIC, and ENABLE_THREADS amonst other things ...

The additional includes string will, as usual need some work ...

../../../;../../../Simgear;../../src;../../../AL/include;../../../zlib-1.2.3; ../../../freeglut-2.4.0/include;../../../Pre-built.2/include;../../src/include; ../../src/input;../../src/FDM/JSBSim

Again applying the changes for openal, zlib, freeglut and pthreads, I get -

../../../;../../../Simgear;../../src;../../../openal/include;../../../openal/alut/include ;../../../openal/include/al;../../../zlib;../../../freeglut/include; ../../../pthreads;../../src/include;../../src/input;../../src/FDM/JSBSim

And I had to remove -

c:\program files\microsoft platform sdk\include

from Tools -> Options -> Projects and Solutions -> VC++ Directories -> Include Files

since it was loading gl\gl.h from here, and producing errors like ...

c:\program files\microsoft platform sdk\include\gl\gl.h(1152) : error C2144: syntax error : 'void' should be preceded by ';'
c:\program files\microsoft platform sdk\include\gl\gl.h(1152) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
c:\program files\microsoft platform sdk\include\gl\gl.h(1152) : error C2146: syntax error : missing ';' before identifier 'glAccum'
... etc ...

First, I decided to UPDATE my Microsoft Platform SDK to "Microsoft Platform SDK for Windows Server 2003 R2", using the web updater from -
http://www.microsoft.com/downloads/details.aspx ?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
- downloading the 1.4MB PSDK-x86.exe, and running it ... while this took a while - several hours in fact - but it went painlessly ... it also cleaned up some of the earlier SDKs ...

You can also download the individual CAB files, and do it all locally, from -
http://www.microsoft.com/downloads/details.aspx ?FamilyId=484269E2-3B89-47E3-8EB7-1F2BE6D7123A&displaylang=en
- ... some 17 25 MB cab files, plus PSDK-FULL.exe ...

But that did NOT improve the situation. Eventually I tracked it down to HAVE_WINDOWS_H not being defined, which IS defined in config.h ... BUT there is a config.h in the pthreads folder, which gets loaded instead !!! I decide to rename the pthreads config.h to ptw32_config.h, which is it internal 'defined' name anyway ... After re-doing pthreads, I could return to here ...

The next 'problem' was I had to remove auto_gui.cxx from the build. This file no longer exists ...

Of course, there are the USUAL many warnings, like -
warning C4996: 'strdup' was declared deprecated
Message: 'The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details.'
warning C4101: 'e' : unreferenced local variable
warning C4800: 'float' : forcing value to bool 'true' or 'false' (performance warning)
warning C4018: '<' : signed/unsigned mismatch
warning C4305: 'initializing' : truncation from 'double' to 'const float'
warning C4355: 'this' : used in base member initializer list
warning C4305: '=' : truncation from 'double' to 'float'
warning C4244: '=' : conversion from 'double' to 'float', possible loss of data

and maybe some others ;=() these mount into the HUNDREDS ...

I got another strange action on the link. I had stopped the compile a few times, and always thought the compiler tool would clean up any file it was in the middle of, but it seems that is NOT always the case - I got

.\FGDebug\ATCDialog.obj : fatal error LNK1136: invalid or corrupt file

On viewing the file, I note it was MORE THAN CORRUPTED -

07/06/2006 11:49 AM 0 ATCDialog.obj

It had ZERO length ... just deleting this fixed this problem ...

Of course the final EXE link failed, since I have NOT fixed the include libraries ...

Selecting FlightGear, the Project -> Properties -> Linker -> Input -> Additional Dependencies list for Debug showed -

FlightgearLib.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 ssg_d.lib ssgAux_d.lib ul_d.lib pthreadvc2.lib Alut.lib openal32.lib zlibd.lib wsock32.lib advapi32.lib comdlg32.lib shell32.lib user32.lib

And selecting FlightGear, the Project -> Properties -> Linker -> General -> Additional Library Directories for Debug contained -

"FG$(IntDir)";../../../plib/;"../../../Simgear/Projects/VC8/$(IntDir)"; "../../../freeglut-2.4.0/$(IntDir)Static";"../../../Pre-Built.2/lib"; "../../../zlib-1.2.3/projects/visualc6/win32_lib_asm_$(IntDir)";../../../al/lib

Both these must be corrected to match my folder structure, and dependency library names ... dealing with them in pairs, one by one -

(i) FlightgearLib.lib at "FG$(IntDir)" - this is correct.

(ii) Simgear.lib at "../../../Simgear/Projects/VC8/$(IntDir)" - this also appears correct. Note this would require one more 'backup' (../) if I had NOT removed one level of folders during the source copy from the cvs update ...

(iii) fnt_d.lib to ul_d.lib at ../../../plib/ - also appears correct for PLIB ...

(iv) pthreadvc2.lib at "../../../Pre-Built.2/lib" - this is neither the NAME I used, nor the same placement. Mine is pthreadVC2Dbg.lib at ../../../pthreads

(v) Alut.lib at ../../../al/lib - while alut.lib is correct, my placement is ../../../openal/alut/admin/VisualStudioDotNET/alut/$(IntDir)

(vi) openal32.lib at ../../../al/lib - while openal32.lib is corrent, my current placements is -

../../../openal/OpenAL-Windows/Router/$(IntDir)

(vii) zlibd.lib at "../../../zlib-1.2.3/projects/visualc6/win32_lib_asm_$(IntDir)" - This is perhaps the DLL import library. In this instance mine is zlibstat.lib at ..\..\..\zlib\contrib\vstudio\vc8\x86\ZlibStat$(IntDir)

(viii) freeglut_static.lib at "../../../freeglut-2.4.0/$(IntDir)Static" - In my instance this must be changed to freeglut_static.lib at "..\..\..\freeglut\$(IntDir)Static"

(ix) And for good measure wsock32.lib to the version 2, ws2_32.lib ...

My fully corrected strings are given below -

FlightgearLib.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 ssg_d.lib ssgAux_d.lib ul_d.lib pthreadVC2Dbg.lib Alut.lib openal32.lib zlibstat.lib freeglut_static.lib ws2_32.lib advapi32.lib comdlg32.lib shell32.lib user32.lib

"FG$(IntDir)";../../../plib/;"../../../Simgear/Projects/VC8/$(IntDir)"; "..\..\..\freeglut\$(IntDir)Static";"../../../pthreads";
"..\..\..\zlib\contrib\vstudio\vc8\x86\ZlibStat$(IntDir)"; ../../../openal/alut/admin/VisualStudioDotNET/alut/$(IntDir);
../../../openal/OpenAL-Windows/Router/$(IntDir)

It should be NOTED, seldom do I get all this correct on the first try ;=)) It is sometimes a matter of something like trial and error until I get it right. Like in this case I have a bunch of UNRESOLVED EXTERNALS ... some of which are -

FlightgearLib.lib(dialog.obj) : error LNK2019: unresolved external symbol "public: __thiscall PropertyList::PropertyList(int,int,int,int,class SGPropertyNode *)" (??0PropertyList@@QAE@HHHHPAVSGPropertyNode@@@Z) referenced in function "private: class puObject * __thiscall FGDialog::makeObject(class SGPropertyNode *,int,int)" (?makeObject@FGDialog@@AAEPAVpuObject@@PAVSGPropertyNode@@HH@Z)
Simgear.lib(zfstream.obj) : error LNK2019: unresolved external symbol _gzopen referenced in function "public: class gzfilebuf * __thiscall gzfilebuf::open(char const *,int)" (?open@gzfilebuf@@QAEPAV1@PBDH@Z)
Simgear.lib(texture.obj) : error LNK2001: unresolved external symbol _gzopen
and some more for zlib ...
Debug\FlightGear.exe : fatal error LNK1120: 9 unresolved externals
Build log was saved at "file://c:\FG0910-3\flightgear\projects\VC8\Debug\BuildLog.htm"
FlightGear - 17 error(s), 5 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

But, in a strange way, THIS IS GOOD ;=)) Sometimes on the link I can have HUNDREDS of unresolved items ...

(a) Missing zlib items

This is the first time I have tried the 'static' form of zlib ... maybe the 'static' library does not expose these functions? I re-load the zlib projects, and check the zlibvc.def file ... gzopen appears to be there -

gzopen @16

so why was it not resolved in the LINK?

As a quick test, I re-load the zlib solution, and re-load the zlibvc project, and build the DLL version. The output is -

Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibDllDebug
07/06/2006 03:01 PM            18,250 zlibwapi.lib
Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibDllRelease
07/06/2006 03:03 PM           18,250 zlibwapi.lib
Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibDllDebug
07/06/2006 03:01 PM           630,784 zlibwapi.dll
Directory of C:\FG0910-3\zlib\contrib\vstudio\vc8\x86\ZlibDllRelease
07/06/2006 03:03 PM            74,240 zlibwapi.dll

Then adjust the linker strings to -
FlightgearLib.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 ssg_d.lib ssgAux_d.lib ul_d.lib pthreadVC2Dbg.lib Alut.lib openal32.lib zlibwapi.lib freeglut_static.lib ws2_32.lib advapi32.lib comdlg32.lib shell32.lib user32.lib

"FG$(IntDir)";../../../plib/;"../../../Simgear/Projects/VC8/$(IntDir)"; "..\..\..\freeglut\$(IntDir)Static";"../../../pthreads"; "..\..\..\zlib\contrib\vstudio\vc8\x86\ZlibDll$(IntDir)"; ../../../openal/alut/admin/VisualStudioDotNET/alut/$(IntDir); ../../../openal/OpenAL-Windows/Router/$(IntDir)

NOPE! ;=(( that did NOTHING about zlib!!!

Linking...
FlightgearLib.lib(dialog.obj) : error LNK2019: unresolved external symbol "public: __thiscall PropertyList::PropertyList(int,int,int,int,class SGPropertyNode *)" (??0PropertyList@@QAE@HHHHPAVSGPropertyNode@@@Z) referenced in function "private: class puObject * __thiscall FGDialog::makeObject(class SGPropertyNode *,int,int)" (?makeObject@FGDialog@@AAEPAVpuObject@@PAVSGPropertyNode@@HH@Z)
Simgear.lib(zfstream.obj) : error LNK2019: unresolved external symbol _gzopen referenced in function "public: class gzfilebuf * __thiscall gzfilebuf::open(char const *,int)" (?open@gzfilebuf@@QAEPAV1@PBDH@Z)
Simgear.lib(texture.obj) : error LNK2001: unresolved external symbol _gzopen
Simgear.lib(sg_binobj.obj) : error LNK2001: unresolved external symbol _gzopen
Simgear.lib(zfstream.obj) : error LNK2019: unresolved external symbol _gzdopen referenced in function "public: class gzfilebuf * __thiscall gzfilebuf::attach(int,int)" (?attach@gzfilebuf@@QAEPAV1@HH@Z)
Simgear.lib(zfstream.obj) : error LNK2019: unresolved external symbol _gzclose referenced in function "public: class gzfilebuf * __thiscall gzfilebuf::close(void)" (?close@gzfilebuf@@QAEPAV1@XZ)
Simgear.lib(texture.obj) : error LNK2001: unresolved external symbol _gzclose
... etc ...

I have an EARLIER version, that worked fine -
Directory of C:\FG0910-2\zlib-1.2.3\projects\visualc6\Win32_LIB_Debug
04/04/2006 03:31 PM 248,124 zlibd.lib
Directory of C:\FG0910-2\zlib-1.2.3\projects\visualc6\Win32_LIB_Release
04/04/2006 03:31 PM 102,902 zlib.lib

So I adjust the strings again - this is getting BORING ;=()

FlightgearLib.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 ssg_d.lib ssgAux_d.lib ul_d.lib pthreadVC2Dbg.lib Alut.lib openal32.lib zlibd.lib freeglut_static.lib ws2_32.lib advapi32.lib comdlg32.lib shell32.lib user32.lib

"FG$(IntDir)";../../../plib/;"../../../Simgear/Projects/VC8/$(IntDir)"; "..\..\..\freeglut\$(IntDir)Static";"../../../pthreads";" C:\FG0910-2\zlib-1.2.3\projects\visualc6\Win32_LIB_$(IntDir)"; ../../../openal/alut/admin/VisualStudioDotNET/alut/$(IntDir); ../../../openal/OpenAL-Windows/Router/$(IntDir)

THIS WORKS!!!

Now just ONE(1) unresolved external ... PropertyList::PropertyList ...

(b) Missing PropertyList::PropertyList item

This usually denotes some additional source which has not yet been added to the solution file ... A COMMON PROBLEM ... while the developers TRY to keep up with the changing source list, a CVS update can lag behind the facts ...

Regrettably, it seems the new file search algorithm does NOT include file NOT already in the 'solution' if you choose to 'search the solution" ;=(( You have to choose to search a folder, and then you get every file in that folder ... but such a search yielded -

C:\FG0910-3\flightgear\src\GUI\property_list.cxx(103):PropertyList::PropertyList(int minx, int miny, int maxx, int maxy, SGPropertyNode *start) :
C:\FG0910-3\flightgear\src\GUI\property_list.cxx(120):PropertyList::~PropertyList()

... etc, but this file property_list.cxx was NOT included in the solution yet ;=((

I AM EVENTUALLY REWARDED WITH -

Linking...
Build log was saved at "file://c:\FG0910-3\flightgear\projects\VC8\Debug\BuildLog.htm"
FlightGear - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

PHEW!!! This does not yet face the problem of (a) the missing functions in PLIB, but since flightgear does not presently appear to use these, then this can be left, and (b) why I could NOT get a new copy of zlib.lib functioning. The only difference here is that IIRC I started last time using the MSVC6 DSW build file, rather than the newer MSVC8 solution file ... but both were built with MSVC8 ...

top

10. Running flightgear

After the build, we come to the running of flightgear. First, the full flightgear data directory must be available - I create a data folder, change into that folder, and make a copy of the CVS updated data, with -

> xcopy /e c:\fgcvs\flightgear\data\*.* .

AND, more importantly, the dependant components built using a DLL have to be 'installed' somewhere ...

In simple terms, Windows begins searching for a DLL in the folder of the EXE runtime binary file, so one choice is to copy all the necessary DLL files to this folder. Alternatively, windows will then search using the PATH variable in the environment. This list can be seen by entering PATH at the command prompt ... in my case it is presently -

PATH="C:\Program Files\Microsoft DirectX SDK (April 2006)\Utilities\Bin\x86";C:\WINDOWS\system32;C:\

WINDOWS;C:\WINDOWS\System32\Wbem;c:\MDOS;C:\Perl\bin\;c:\PHP;c:\Program Files\Microsoft SQL Server\9

0\Tools\binn\;C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft

Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin

Theoretically, I could use ANY of these PATHS ... There is one exception, unless a fix I submitted to OpenAL has been implemented, and that is OpenAl32.DLL and its partner, wrap_oal.dll ... The previous, and perhaps current OpenAL32.DLL statically loads this wrap_oal.dll, and imports some addresses from it, but it does not, or did not, search all the PATH folders ... It only searched the so called 'system' folder, usually c:\WINDOWS\System32 ... so this add a slight restriction ...

There is no particular problem using the 'system' folder, c:\WINDOWS\System32, provided there is no conflict with the MASS of DLL files already in there ... that is nearly 1500 DLL files at last count on my system ... So what are the needed DLL files -

FlightGear, SimGear, zlib, freeglut, and PLIB, in my case, are all static libraries, so their code is now embedded in the FlightGear.exe. The others are -

openal - OpenAL32.DLL, wrap_oal.dll and alut.dll, and

pthreads - pthreadVC2Dbg.DLL

I decide to copy then all to my 'system' folder.

You have to REMEMBER that you have done this, since this is permanently 'installing' them, so to speak. If you change or update any of them, then you MUST remember to copy the new incarnation to the SAME place ... And for those of you using cygwin to build flightgear, I have notes that cygwin ALSO uses this folder - in a funny cygwindrive/c/windows/system32 - so there can be some conflicts with this build ...

To make sure I can repeat this, I use a batch file to do the copying, BUT at the same time I build a batch file to be able to DELETE them again ... and the copy batch file checks, and warns if the DLL already exists ... the full contents of my batch files are given below ... of course, you have to decide whether you want to copy the Debug or the Release DLL files ... these reside in the FG0910-3 root ...

Finally, I construct a rfg.bat file -

@set TEMP1=flightgear\projects\VC8\Debug\FlightGear.exe
@if NOT EXIST %TEMP1% goto ERR1
@set TEMP2=data
@if NOT EXIST %TEMP2%\preferences.xml goto ERR2
%TEMP1% --fg-root=%TEMP2%
@goto END
:Err1
@echo can NOT locate file [%TEMP1%] ... check name and location ...
@goto END
:Err2
@echo can NOT locate file [%TEMP2%\preferences.xml] ... check name and location ...
@goto END
:END

This, like the others, is in the C:\FG0910-3 root folder ... being impatient I tried the Debug version, since I had built this first, after I had done copyall, but this STALLED during the load ... so then I finished off build the Release version ...

And switch the batch file to release, and add in my 'favourite' aircraft and fdm ...

%TEMP1% --fg-root=%TEMP2% --fdm=ufo --aircraft=ufo

AND FLIGHTGEAR RUNS FINE - slowly as always - just 1-2 frames per second - BUT IT RUNS ;=)) HOWEVER, after I updated my ATI video card drivers from the manufacturers site, I consistently got 50-60 frames per second. I can only kick myself that I did not do this EARLIER ;=))

top

11. DLL COPY BATCH FILES

@REM copy1.bat
@REM expected command is the DLL name, and its SOURCE folder as two arguments
@if "%3." == "." goto DOCOPY
@if "%3." == "D." goto DODELETE
@if "%3." == "d." goto DODELETE
@echo Usage DLL path 'D|d'
@goto END

:DODELETE
@set TEMPDD=C:\WINDOWS\System32
@set TEMP1=%1
@set TEMPD=%TEMPDD%\%TEMP1%
@if NOT EXIST %TEMPD% goto NODELETE
del %TEMPD%
@goto END
:NODELETE
@echo It appears [%TEMPD%] has already been removed ...
@goto END
:DOCOPY
@set TEMPDD=C:\WINDOWS\System32
@set TEMP1=%1
@set TEMP2=%2
@set TEMPS=%TEMP2%\%TEMP1%
@if NOT EXIST %TEMPS% goto ERR1
@set TEMPD=%TEMPDD%\%TEMP1%
@if NOT EXIST %TEMPD% goto COPY
@echo WARNING %TEMPD% already EXISTS!
@DIR %TEMPD%
@echo *** OVERWRITE THIS FILE? *** Ctrl+C to ABORT copy ...
@pause
:COPY
copy %TEMPS% %TEMPDD%\.
@goto END
:ERR1
@echo Can NOT locate file [%TEMPS%] ... check name and source ...

@goto END
:END

@REM copyall.bat
call copy1 alut.dll C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Release
call copy1 wrap_oal.dll C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Release
call copy1 OpenAL32.dll C:\FG0910-3\openal\OpenAL-Windows\Router\Release
call copy1 pthreadVC2.dll C:\FG0910-3\pthreads

@REM delall.bat
call copy1 alut.dll C:\FG0910-3\openal\alut\admin\VisualStudioDotNET\alut\Release D
call copy1 wrap_oal.dll C:\FG0910-3\openal\OpenAL-Windows\OpenAL32\Release D
call copy1 OpenAL32.dll C:\FG0910-3\openal\OpenAL-Windows\Router\Release D
call copy1 pthreadVC2.dll C:\FG0910-3\pthreads D

top or index

EOF - fg-up-01.doc