FG OSG BUILD - MSVC7

index

in-page jumps: preamble -|- folders -|- build -|- runtime -|- debugging -|- downloads -|- quick start -|- missing items -|- postscript -|- end

Preamble:

2007-04-23 - Having SUCCESSFULLY built and flown FlightGear using MSVC8, and FAILED using MSVC6, it seemed time to try MSVC7 again ;=)) That is Microsoft Development Environment 2003, Version 7.1.6030. This is the original Microsoft Visual C++ .NET, with Microsoft Visual Studio .NET 2003 Service Pack 1 (KB918007) applied, and the Platform SDK installed, herein referred to as MSVC7.

Read the postscript for a strange FAILURE of the MSVC7 compiler. After I separated the SimGear and FlightGear projects, and did all the work in setting them up separately, and compiling the Debug configuration, I decided to give my MSVC7 single solution ANOTHER try, and GOT NO FREEZE on the Debug configuration build. Many mysteries ;=)) So now I am back on track to produce a single solution files containing all 24 projects. Unfortunately the release version still aborts, with a simple message 'Unknown exception in the main loop. Aborting...', but at least I now have the Debug version to try ... on with the FULL story ...

FlightGear depends on a considerable number of other 'libraries', which must be downloaded, and built first, then FG source and base data. Where possible, I tend to use the CVS (or SVN) development sources. And I tend to use the COMMAND LINE versions of these tools, since this facilitates the construction of a single batch file to update all the sources at one time.

CVS - Concurrent Versions System - I have zipped (MD5: 58a6ae5eb66eb1641e441f9e86d5a791) my client version 1.11.17, Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors. CVS may be copied and used only under the terms of the GNU General Public License. At - http://ftp.gnu.org/non-gnu/cvs/binary/stable/x86-woe/ - later versions can be found, up to cvs-1-11-22.zip 10-Jun-2006 ... There are also several GUI version available, but I have never tried these, and have heard reports that they are quite difficult to set up.

SVN - Subversion - This is available from - http://subversion.tigris.org/ - I downloaded svn-1.4.0-setup.exe which does a nice windows setup, including automatically adding a path to the svn.exe, so it was all easy. I note there is a later svn-1.4.3-setup.exe, or you can download one of the zip files, and do your own setup. You may have to right mouse click, and use 'Save Target As...' to download these files in windows.

The link were valid at the time of this pages creation. In no particular order these are :- openal, freeglut, PLIB, OpenSceneGraph, OpenThreads, zlib, simgear, pthreads (optional), and flightgear source and base data -

With all the above sources, (and data) downloaded, you are ready to begin a build, first of the dependant libraries, and then FlightGear itself ...

top

Folder Structure:

I place all these source in a single folder I call FGCVS ... This is a view of the subdirectories in that folder. Note it contains a lot more than just the above mentioned source, but none of these additional items are specifically needed for FG ... It should also be noted I have unpacked zlib into to same folder, even though it is not a CVS/SVN source ...

view of my download folders

You need to emulate this folder structure if you want to use the setup and compile tools given at the end of this page.

For various reasons, including the fact that today big hard disk prices are very reasonable, I never build in the above, what I call 'updateable' folders. I first XCOPY the required sources to a new work folder. To make all this EASY I have a batch file, SETUPFG.BAT, to create a new set of folder, in a chosen 'work' folder, and copy the required sources into place. This batch file is included in the vc7sln01.zip given below. After this setupfg.bat has run, I have a simpler set of WORK folders, in my case in a root folder G:\FG\MSVC7, containing the desired sources :-

view of work folders

The first folder, 'bin', is where all the final binary runtime items will reside. The 'data' is a full copy of the base FG data folder. In here I can also download, and add additional scenery, and additional aircraft models, etc. The 'fgfs' is the make, or build folder, where the single fgfs.sln resides.

top

The Build:

In this case I am using MSVC7 - each component, and finally FG could be loaded individually, and built separately, naturally some before others, but I have created a single solution file, fgfs/fgfs.sln, and set of 24 MSVC7 project files, that includes all the required components, set to compile first, then finally FlightGear. Due to the changing sources, this is always a work-in-progress. Quite frequently files have to be added or delete from certain projects, and invariably, since this is nearly all ongoing development source, sometimes code fixes have to be made.

To try to ease some of the 'pain' of this latter item, any modified sources are also included in vc7sln01.zip, in vc7chg01.zip. But you should first try the build WITHOUT these modified files. Sometimes, hopefully by the time you are using this, the relevant fixes have made it into the particular CSV/SVN development source. All that should be required is to unpack vc7sln01.zip into your chosen 'work' folder, allowing an overwrite of the existing project files.

As well as the modified source zip file, unpacking the vc7sln01.zip will also add a vc7cfg01.zip to the 'work' folder. This must also be unpacked, using the folder names ... Load fgfs\fgfs.sln file in MSVC7, select either 'Debug' or 'Release' configuration and build ... Sometimes many other 'configurations' are listed, BUT ONLY 'Debug' and 'Release' have been fully tested. Using any other configuration, and you are on your own ;=))

It is a GOOD IDEA to CHECK Menu -> Build -> Configuration Manager to ENSURE the Active Solution Configuration: Debug or Release, that each project has the correct 'Configuration' selected. For Debug, each should read Debug, except perhaps zlib, which should read 'LIB Debug'. Likewise when Release is selected, they should all be Release, except perhaps zlib, which should read 'LIB Release'. I may have corrected this somewhat by the time you receive the solution set.

For example, in building from a previous to develop the next, I have found that sometimes I have to delete files, and/or tp add files, and in one case, changed source folder (ac3d to ac) in the OSG ... this is particularly in OS, simgear and flightgear which are very active projects ... these type of ongoing changes are inevitable ... it would be nice if I could automate a way, but that would be quite involved, perhaps impossible ;=() It would involve writing a unix/linux type makefile interpreter, but, for example,  OSG used GNUmakefile, while simgear and flightgear use makefile.am ...

This build, with MSVC7, is using the runtime library 'Multithreaded DLL' (/MD), and 'Multithreaded Debug DLL' (/MDd) respectively! When you create a new project in MSVC7 this is the default, but many prerequisite projects use /MT-/MTd, perhaps some with /ML-/MLd. 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.

Also, as previous, I had to make some minor code changes in Router\alc.cpp ...

1. I had to un-define HAVE_VISTA_HEADERS, since I don't have these installed ...

#ifndef __MINGW32__
#define _CRT_SECURE_NO_DEPRECATE // get rid of sprintf security warnings on VS2005
#undef HAVE_VISTA_HEADERS
#endif

2. And a little later, change -

#ifndef __MINGW32__
to
#if !(defined (__MINGW32__) || defined (_MSC_VER))

This second change is NOT required, if you have the file <atlconv.h> available, and is thus NOT included in the change ZIP. I have posted this to the OpenAL development board in the hope they will eventually change it in CVS ...

When the final link is successful, run UPD.BAT - this can be run with a 'D' parameter - like> upd d to also copy the debug versions to the 'bin' folder. In the 'bin' folder there is also an OpenAL folder. In this folder is another UPD.BAT, to copy the sound DLL shared libraries to your system folder, hard coded as C:\WINDOWS\System32.  If your windows is installed in other than this folder, then this upd.bat will need to be adjusted. If you already have these sound DLL shared library files installed, then it will refuse to do anything until these are deleted ...

Now you are ready to run flightgear. There is a number of batch files, in rfgbats02.zip, which expands to the 'bin/bats' folder, to provide some initial scenarios. rfg.bat is the simplest with a content of :-

cd ..
FlightGear --fg-root=..\data --fog-disable --timeofday=noon --prop:/sim/rendering/fps-display=true
cd bats

You will note a number have 'noai' in their name. This is because I get a CRASH after about 5-10 minutes if I do not disable AI planes, but you might have more luck ;=)) You will note each uses ..\data as the path to the base data and scenery. If you did not copy the base data during setupfg then this will have to be adjusted to where you have installed at least the base data, and/or additional scenery ...

Linking...
Build log was saved at "file://g:\FG\MSVC7\FlightGear\Release\BuildLog.htm"
FlightGear - 0 error(s), 3152 warning(s)
---------------------- Done ----------------------
    Build: 24 succeeded, 0 failed, 0 skipped

Of course, in the above link, I am IGNORING the 3152 warnings!!! Hopefully NOT at my peril ;=)) Maybe one of them caused the Release version of FlightGear.exe to CRASH on loading??? What a LOT OF EFFORT maybe for naught ;=().

top

Debugging FlightGear:

Debugging is never particularly easy. It requires considerable patience, a little understanding of Intel machine code, and some DLL setup steps. Normally the MSVC built-in debugger can be started from Menu -> Debug -> Start (F5), while on the Debug configuration, but in this case, FlightGear depends on a number of DLL Shared Libraries, thus without setup you will get dialogs like -

missing DLL shared library file

As it states, it is unable to locate a component, in this case osgd.dll. I have written an upddbg.bat batch file, to copy the necessary 'components' into the SAME folder as FlightGear.EXE - namely COPY osgd.dll, osgDBd.dll, osgdb_acd.dll, osgdb_rgbd.dll, osgUtild.dll, OpenThreadsWin32d.dll, and pthreadVC2.dll TO the folder FlightGear/Debug/., then the debug load should proceed.

Next is to decide where to set a break point. The actual OS entry point is in bootstrap.cxx, at -

// Main entry point; catch any exceptions that have made it this far.
int main ( int argc, char **argv ) {

But, after setting up an exception block, it calls fgMainInit(argc,argv), which is in main.cxx. But at the end of this function is passes off control to fgOSMainLoop(), in fg_os.cxx, which in turn calls glutMainLoop(), from which is NEVER returns!

Control returns regularly to fgIdleFunction(), back in main.cxx, where it tumbles down an giant if based on the idle_state variable, until it reaches the value of 1000, when control is again shifted to the fgMainLoop() callback, in main.cxx, which does the updates for each time loop, including determining the frame rate. I have sometimes put a trap in each of the idle_state if actions to trace a particular difficult 'startup' bug.

However, in this case, the last message output to the console was the message in this exception block, but setting a break point here is too late - the exception has fired, and I want to see what caused the exception. To learn more, I run FG with the command line -

FlightGear --fg-root=..\data --log-level=debug

I even have a batch file, rfglogdbg.bat, in bin/bats to redirect the console output to a file, because it can be quite long, and may scroll off the console screen. Running this batch file, and viewing templog2.txt at the end shows me that the last four console outputs are -

  press-cockpit-button
  release-cockpit-button
Initializing scenery subsystem
Unknown exception in the main loop. Aborting...

This mean I can set a break point at the point where 'Initializing scenery subsystem' is output. One of the beauties of using a single solution file, is that the search for this phrase will be across the entire solution. So a 'find' shows -

Find all "Initializing scenery subsystem", Subfolders, Find Results 1, Current Project:
..\FlightGear\FlightGear.vcproj, "*.*"
G:\FG\MSVC7\FlightGear\src\Scenery\scenery.cxx(71):  
  SG_LOG( SG_TERRAIN, SG_INFO, "Initializing scenery subsystem");
Total found: 1    Matching files: 1    Total files searched: 815

So I set a debug trap (a break point) in this code -

// Scenery Management system
FGScenery::FGScenery() :
  center(0, 0, 0)
{
    SG_LOG( SG_TERRAIN, SG_INFO, "Initializing scenery subsystem" );
}

This should happen before the exception, and I can carefully trace onwards from here. The debug load takes a LONG TIME. This is partly because all memory is allocated, set to a pattern, with a trailer to watch for over runs, and of course all the symbols need to be loaded, so the 'reading airport & navigation data' load step seems to take forever ...

Also, while the modern debugger is quite good, always remember to SAVE any important work before starting the debugger - if something goes wrong with the debugging process rarely the machine can be FROZEN! And I usually exit most other applications to give the most memory to the debugger ...

But as expected, I reach the trap in FGScenery initialization. Tracing onwards, I find the exception occurs in -

        globals->get_scenery()->init();

so I carefully trace into here ... then I find it is in -

    scene_graph->addChild( terrain_branch.get() );

I find the exception occurs in the code in Group.cpp -

if (child->getNumChildrenWithOccluderNodes()>0 ||
            dynamic_cast<osg::OccluderNode*>(child))
        {

The TRACE STACK, one instruction BEFORE the exception shows -

msvcr71d.dll!FindCompleteObject(void * * inptr=0x07ea89e8)  + 0x17
msvcr71d.dll!__RTDynamicCast(void * inptr=0x07ea89e8, long VfDelta=0, void * 
 SrcType=0x1022d808, void *TargetType=0x1022e374, int isReference=0)  + 0x43
osgd.dll!osg::Group::insertChild(unsigned int index=0, osg::Node * child=0x07ea89e8)
 Line 135 + 0x23
osgd.dll!osg::Group::addChild(osg::Node * child=0x07ea89e8)  Line 70    C++
FlightGear.exe!FGScenery::init()  Line 88 + 0x30
FlightGear.exe!fgIdleFunction()  Line 730 + 0x24
FlightGear.exe!GLUTidle()  Line 122 + 0x11
FlightGear.exe!glutMainLoop()  Line 1510 + 0x8
FlightGear.exe!fgOSMainLoop()  Line 155
FlightGear.exe!fgMainInit(int argc=2, char * * argv=0x018e60c0)  Line 1034
FlightGear.exe!main(int argc=2, char * * argv=0x018e60c0)  Line 209 + 0xd

The errant code - well not really - but the code that causes the exception -

FindCompleteObject:
00357810  push        ebp
00357811  mov         ebp,esp
00357813  sub         esp,8
00357816  mov         eax,dword ptr [inptr]
00357819  mov         ecx,dword ptr [eax]
0035781B  mov         edx,dword ptr [ecx-4]
0035781E  mov         dword ptr [pCompleteLocator],edx
00357821  mov         eax,dword ptr [pCompleteLocator]
00357824  mov         ecx,dword ptr [inptr]
00357827  sub         ecx,dword ptr [eax+4]

At that moment, EAX, loaded from [pCompleteLocator], which was set from EDX being loaded from [inptr] pointer - 4, is ZERO, and the EXCEPTION is to load ECX from [EAX+4]. As I suspected, the many, many WARNINGS about dynamic_cast have come back to bite me ;=()

The WARNINGS were ALL of the FORM -

g:\FG\MSVC7\OpenSceneGraph\include\osg\Switch(36) : warning C4541: 'dynamic_cast' used 
on polymorphic type 'osg::Object' with /GR-; unpredictable behavior may result

WOW, this turned out to be AS SIMPLE AS switching 'Enabling Run-Time Type Info' ( FlightGear -> Property Pages -> Configuration Properties -> C/C++ -> Language ) to 'Yes' (/GR). I note this is the DEFAULT in MSVC8!

Setting it to YES (/GR) in the Debug configuration REMOVED all 'warning C4541' from the build, but maybe I have to apply it to ALL projects, both configurations, at least those of OSG, or including OSG, which is where they all emanate from.

HA! The projects 'Core osg', 'Core osgBD', 'Core osgUtil', 'OpenThreads', 'osgPlugin ac3d', and 'osgPlugin rgb' ALREADY HAVE THIS OPTION SET TO YES (/GR)!!! This should mean only changing simgear and flightgear to YES also ... Re-compiling and linking the Release GETS ME FLYING ;=))

For some idiot reason the keyboard does not work, but the mouse and joystick do, so I take the default Cessna off, slewing left across the grass, and successfully get it into the AIR without hitting anything. ;=))

THE MORAL OF THE STORY -
DO NOT BLITHELY IGNORE _ALL_ COMPILER WARNINGS ;=))

Must look into why the English keyboard FAILED to register in PLIB, but the CRASH SEEMS GONE, so this was a quite successful initial debug session. Of course, I also re-build the Debug version to make sure my VERY STRANGE MSVC7 failure has not returned, and ready to debug why the KEYBOARD FAILS ...

But in general NOW QUITE HAPPY ;=))

top

Downloads:

1. fgvc7rt01.zip - Set of WIN32 runtime binaries - MD5 = aeb0442bb17e1e46673ad22adcbd6c24 - contents

  Length   Size  Ratio    Date     Time   Name
  ------   ----- -----    ----     ----   ----
 3588096 1440235  60%  25/04/2007  17:50  bin\FlightGear.exe
   28672    6560  78%  23/04/2007  19:29  bin\OpenThreadsWin32.dll
 1286144  444847  66%  23/04/2007  19:36  bin\osg.dll
  253952   86614  66%  23/04/2007  19:40  bin\osgDB.dll
  122880   44161  65%  23/04/2007  19:43  bin\osgdb_ac.dll
   18432    7142  62%  23/04/2007  19:43  bin\osgdb_rgb.dll
  782336  291433  63%  23/04/2007  19:39  bin\osgUtil.dll
   52736   21440  60%  24/04/2007  13:26  bin\pthreadVC2.dll
 ------- -------  ---                     -------
 6133248 2342432  62%                           8

2. vc7sln01.zip - Set of MSVC7 build files - MD5 = 96ee6a4869e85d5a331a5cf2aace34eb - contents

  Length   Size  Ratio    Date     Time   Name
  ------   ----- -----    ----     ----   ----
    3690    1715  54%  26/04/2007  15:02  README.fgfs.txt
   55790    3768  94%  23/04/2007  18:25  fgfs\fgfs.sln
    3881     962  76%  24/04/2007  13:15  OpenAL\OpenAL-Windows\Alc\ALc.vcproj
    3881     962  76%  24/04/2007  13:15  OpenAL\OpenAL-Windows\Alu\ALu.vcproj
  169483    4533  98%  22/04/2007  13:38  OpenSceneGraph\VisualStudio\osg\osg.vcproj
   34816    2114  94%  22/04/2007  13:38  OpenSceneGraph\VisualStudio\osgDB\osgDB.vcproj
   50582    2432  96%  22/04/2007  13:38  OpenSceneGraph\VisualStudio\osgUtil\osgUtil.vcproj
  262292    9066  97%  25/04/2007  17:34  FlightGear\FlightGear.vcproj
   12097    1432  89%  24/04/2007  13:15  OpenAL\OpenAL-Windows\OpenAL32\OpenAL32.vcproj
   13134    1595  88%  22/04/2007  13:38  OpenThreads\win32_src\OpenThreads.vcproj
    7545    1294  83%  24/04/2007  13:15  OpenAL\OpenAL-Windows\Router\Router.vcproj
   69745    2752  97%  25/04/2007  17:34  SimGear\source\SimGear.vcproj
    5005     974  81%  24/04/2007  13:15  PLIB\src\fnt\fnt.vcproj
   16894    1317  93%  24/04/2007  13:15  freeglut\freeglut_static.vcproj
    6910     994  86%  24/04/2007  13:15  PLIB\src\js\js.vcproj
    7138    1070  86%  24/04/2007  13:15  PLIB\src\net\net.vcproj
   12560    1662  87%  22/04/2007  13:38  OpenSceneGraph\VisualStudio\osgPlugins\ac3d\ac3d.vcproj
   10012    1585  85%  22/04/2007  13:38  OpenSceneGraph\VisualStudio\osgPlugins\rgb\rgb.vcproj
    5753    1243  79%  22/04/2007  13:38  pthreads\pthread.vcproj
   11146    1142  90%  24/04/2007  13:15  PLIB\src\puAux\puAux.vcproj
   16416    1268  93%  24/04/2007  13:15  PLIB\src\pui\pui.vcproj
    5939     978  84%  24/04/2007  13:15  PLIB\src\sg\sg.vcproj
   45323    1653  97%  24/04/2007  13:15  PLIB\src\ssg\ssg.vcproj
    6019     970  84%  24/04/2007  13:15  PLIB\src\util\ul.vcproj
   45185    2378  95%  22/04/2007  13:38  zlib-1.2.3\projects\visualc6\zlib.vcproj
   12834    1494  89%  24/04/2007  12:00  OpenAL\alut\admin\VisualStudio6\alut\alut.vcproj
    4073    4073   0%  20/04/2007  15:27  rfgbats02.zip
    3174    3174   0%  22/04/2007  13:59  vc7cfg01.zip
   13304   13304   0%  22/04/2007  13:54  vc7chg01.zip
    4226    1426  67%  21/04/2007  11:20  setupfg.bat
    1568     583  63%  19/03/2007  15:13  upd.bat
    2084     607  71%  25/04/2007  11:26  upddbg.bat
    2170     523  76%  26/04/2007  15:07  zipall.bat
      47      45   5%  26/04/2007  14:16  zipbats.bat
      46      45   3%  26/04/2007  14:14  zipcfg.bat
      46      45   3%  26/04/2007  14:51  zipchg.bat
      42      42   0%  26/04/2007  14:06  ziprt.bat
      46      45   3%  26/04/2007  14:04  zipsln.bat
     100      68  32%  26/04/2007  14:14  cfglist.txt
      38      38   0%  26/04/2007  14:52  chglist.txt
     892     294  68%  26/04/2007  14:01  slnlist.txt
 ------- -------  ---                     -------
  925926   75665  92%                          41

Or you can go directly to the zip download page on the server that houses these zips ... or to my specific download page ... (MD5 (rfgbats02.zip) = d56c665199a141a5cb80e024288f7414) is a set of updated (2007-04-20) batch files, for the bin/bats folder.

top

Quick Start (using vc7sln01.zip) - WHEN AVAILABLE

This is a somewhat abbreviated version ;=))

If this is your first run, you may have to 'Unblock' the net communications -

Windows NET protection dialog

This will depend on your security settings, although, unless you have specifically enables some 'net' actions, flightgear does not really use this channel. I think this dialog occurs when 'socket' library is initialized in PLIB, and not only when a socket is specifically opened.

As some examples of the command line options, you could also download the fgvc8rt04.zip and extract all the BATCH files into the bin/bats folder, or directly download some updated (20070420) batch files,  (MD5 (rfgbats02.zip) = d56c665199a141a5cb80e024288f7414), and extract them , using the folder names ...

top

Missing Items

Since this is NOT an automated build system, and many of the projects are very active, the VCPROJ files can become out-of-date very quickly. This is usually evidenced by the fact that there are 'missing files' during the build, or 'unresolved externals' during the final link. This usually means that the source file list, for that particular project, has changed since the build system was last updated.

Aside from the quite drastic cvs 'backtracking' - that is do a cvs update using an Apr 21, 2007 date - not tried nor recommended - the only thing that can be done about the 'missing files' is to delete them from the particular project, and continue with the build. The 'unresolved externals' usually means that some NEW file, or files, has/have been added, and now that file, or files, must be added to particular project of the build system.

NOTE: These particular fixes have been done, but are left here as some 'samples' of the type of 'fixes' that are sometimes required.

Example 1: missing file

encoder.cxx
c1xx : fatal error C1083: Cannot open source file: '.\src\Instrumentation\encoder.cxx': 
No such file or directory

I just deleted this files from the FlightGear project, and continued the build.

Example 2: unresolved external

Linking...
altimeter.obj : error LNK2019: unresolved external symbol "public: __thiscall 
FGAtmoCache::~FGAtmoCache(void)" (??1FGAtmoCache@@QAE@XZ) referenced in function 
"public: __thiscall FGAltimeter::~FGAltimeter(void)" (??1FGAltimeter@@QAE@XZ)

How to FIND the missing file? Using grep, or a grep-like tool you can search for the source (in *.c, *.cxx, *.cpp files) that contains 'FGAtmoCache'. In this case it showed up in FlightGear/src/Environment/atmosphere.cxx, which must then be added to the FlightGear project.

Example 3: unresolved external

Linking...
NasalSys.obj : error LNK2019: unresolved external symbol _naInit_utf8 referenced 
in function "public: virtual void __thiscall FGNasalSys::init(void)" (?init@FGNasalSys@@UAEXXZ)

Again, searching the SimGear source for 'naInit_utf8', it is found in SimGear/simgear/nasal/utf8lib.c, thus this file is added to the SimGear project.

Example 4: unresolved external

Linking...
NasalSys.obj : error LNK2019: unresolved external symbol _naInit_thread referenced in function 
"public: virtual void __thiscall FGNasalSys::init(void)" (?init@FGNasalSys@@UAEXXZ)

Searching the SimGear source this time, for ' naInit_thread', it is found in SimGear/simgear/nasal/threadlib.c, thus this file is added to the SimGear project. And that does the trick.

Notice, I tend to work on the missing items 1 by 1, since sometimes the inclusion of a new file may require other new files to be added. Also I try to add it specifically to the appropriate 'project' ... you can verify, at least for simgear and flightgear the full set of source files, by carefully reading all the makefile.am files ...

top

Postscript - Strange Compiler Failure

2007-04-23 UGH! While I was able to do the complete Release compile, MSVC7 failed (STALLED) on the Debug configuration compile. Microsoft site notes this PROBLEM with MSVC NET 2003, but provides a HOT FIX only to paying customers. My MSVC7 came through a MSDN subscription I had at the time, but I am NOT eligible for any free support calls! Further, when I ran the runtime release FlightGear EXE, it CRASHED, without warning during the load.

2007-04-24 - Of course the FAILURE is using a SINGLE solution file for the 24 projects. Separating SimGear and FlightGear out of the single solution, and compiling them SEPARATELY, in Debug, works fine. BUT THIS MASSIVELY DEFEATS THE PURPOSE OF A SINGLE SOLUTION.

In a 'single' solution, MSVC7 takes care of all the library includes in the link, by virtue of the dependency settings. But when separated out like this, you MUST include every additional library, and a PATH to that library. REAL HARD WORK. BAH!

BUT, after all that 'hard work' I decide to try MSVC7 again using my single solution, with 24 projects, AND THIS TIME IT WORKED. I have no idea what is going on here??? I now can NOT find the MS KB article again on this 'multiple project freeze', so MAYBE it was just a figment of my imagination ;=)) Return to continue ...

top

Happy SIM flying ...

Geoff R. McLane
email address
date: 20070423

index

EOP - fgfs-036.htm

Valid HTML 4.01 Transitional