index
page jumps: preamble -|- folders -|- build -|- runtime -|- downloads -|- quick start -|- missing items -|- end
error jumps: C2374 -|- C2664 -|- C1076 -|- environment -|- C1083 -|- C2597
2007-04-21 - MSVC6 BUILD NOT COMPLETED DUE TO TOO MANY PROBLEMS, BUT MAY STILL ASSIST OTHERS TO GET STARTED. IF ANYONE FINDS A WAY TO COMPILE FLIGHTGEAR, ESPECIALLY SIMGEAR, WITH OSG, USING MSVC6, THEN I WOULD CERTAINLY LIKE TO HEAR FROM THEM ;=))
Go to -
fgfs-045.htm, or later, for a successful build using
MSVC9
and/or to
fgfs-042.htm, or later, for a successful build using MSVC8
and/or to
fgfs-039.htm or later, for a successful build using MSVC7
Download MSVC9 Express Edition - FREE!
MSVC6 Work In Progress
Start of the impossible? Maybe, and as it turned out, YES for me ;=)) Building FlightGear, and all its dependant components using Microsoft Visual C++ Version 6.0 (circa 1994-98), here called MSVC6, may be IMPOSSIBLE. This is MSVC6 with SP5 applied.
Certainly some projects can be built with no problems, but the quite broken C++ compiler introduces many errors in others. Most can be manually 'fixed' - read a work around can be manually coded - but in the past I have run in to some where I could NOT find a work-around ;=((
This is a random ordered list, sometimes with real code, sometimes with pseudo code, and a suggested fix.
Sample 1:
0001 ... 0002 for( int pos = 0; pos < max; pos++ ) 0003 ... perform some action ... 0004 0005 for( int pos = 0; pos < max; pos++ ) 0006 ... perform another action ... 0007 ...
will produce
source file name(5) : error C2374: 'pos' : redefinition; multiple initialization source file name(2) : see declaration of 'pos' Error executing cl.exe
Sample 1 FIX:
Move the variable out of the 'for', and place it near the top of the function, like
... int pos; for( pos = 0; pos < max; pos++ ) ... perform some action ... for( pos = 0; pos < max; pos++ ) ... perform another action ... ...
This can output an enormous error string, like -
Simplifier.cpp G:\FG\13-MSVC6\OpenSceneGraph\src\osgUtil\Simplifier.cpp(947) : error C2664: 'class std::_Tree<class osg::ref_ptr<struct EdgeCollapse::Edge>,class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::set<class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::_Kfn,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::iterator __thiscall std::set<class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::insert( class std::_Tree<class osg::ref_ptr<struct EdgeCollapse::Edge>,class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::set<class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::_Kfn,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::iterator,const class osg::ref_ptr<struct EdgeCollapse::Edge> &)' : cannot convert parameter 2 from 'class std::_Tree<class osg::ref_ptr<struct EdgeCollapse::Edge>,class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::set<class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::_Kfn,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::iterator' to 'const class osg::ref_ptr<struct EdgeCollapse::Edge> &' Reason: cannot convert from 'class std::_Tree<class osg::ref_ptr<struct EdgeCollapse::Edge>,class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::set<class osg::ref_ptr<struct EdgeCollapse::Edge>,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::_Kfn,struct std::less<class osg::ref_ptr<struct EdgeCollapse::Edge> >,class std::allocator<class osg::ref_ptr<struct EdgeCollapse::Edge> > >::iterator' to 'const class osg::ref_ptr<struct EdgeCollapse::Edge>' No constructor could take the source type, or constructor overload resolution was ambiguous
With such a large output, it is HARD to find the actual error string -
cannot convert parameter 2 from <something> to <something else>
and is quite misleading to read the final 'ambiguous' line ;=((
The code line that caused this furor is deceptively simple -
edges2UpdateErrorMetric.insert(newEdges.begin(), newEdges.end());
There is no 'generic' fix to this type of error, and for the moment will simply insert a // ***TBF*** in front of the line, just to be able to get on with the build, to be able to point out other errors, intending to come back to this 'marker' later ...
Example:
--------------------Configuration: osgPlugin ac3d - Win32 Release-------------------- Compiling... ac3d.cpp C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\xtree(598) : fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\xtree(103) : while compiling class-template static data member 'unsigned int std::_Tree<osg::ref_ptr<osg::StateSet>, osg::ref_ptr<osg::StateSet>,std::set<osg::ref_ptr<osg::StateSet>,std::less <osg::ref_ptr<osg::StateSet> >,std::allocator<osg::ref_ptr<osg::StateSet > > >::_Kfn,std::less<osg::ref_ptr<osg::StateSet> >, std::allocator<osg::ref_ptr<osg::StateSet> > >::_Nilrefs' Error executing cl.exe.
Reading the MSDN Library - October 2001, it states, in part -
/Zm (Specify Memory Allocation Limit)
The /Zmnumber option determines the compiler's memory allocation limit. The number argument is a scaling factor, with a default value of 100 (that is, 100%). The maximum value is 2000.
In this case, for the project 'osgPlugin ac3d', I tried adding /Zm200 ... and that did the trick ... amazing huh! ;=))
In using the Osg DSP files, frequently two 'environment' variables were used, namely $(PlatformName) and $(ConfigurationName) ... MSVC6 does not 'understand' these variables, and reports all sorts of 'silly' fatal errors, like can not open \\vc6.pdb. This is because the variable $(PlatformName) expands to a BLANK.
The simple solution was to manually go through the OSG DSP files, and convert $(PlatformName) to Win32, and convert $(ConfigurationName) to 'Release' and 'Debug' appropriately.
Then OSG started to compile ...
Many times this is just due to an incorrect or insufficient 'Additional include directories' - see Project Settings -> C/C++ -> Preprocessor tab. Adding or correcting the 'include' path will usually fix this. If it is a 'system' header, then check the Tools -> Options -> Directories tab, Show directories for: Include files. This should show a list like the following -
C:\Program Files\Microsoft Platform SDK\include C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
The first, the 'Platform SDK' is a separate download and install to MSVC6 install, and contains
many updated, and important, what I am calling 'system' headers, included by something like -
#include <windows.h>
Exceptionally, you may come across a header that should NOT be included. The OpenAL Router project is/was a recent example -
--------------------Configuration: Router - Win32 Release-------------------- Compiling... alc.cpp G:\FG\13-MSVC6\OpenAL\OpenAL-Windows\Router\alc.cpp(35) : fatal error C1083: Cannot open include file: 'Mmdeviceapi.h': No such file or directory
The code contained
#ifndef __MINGW32__ #define _CRT_SECURE_NO_DEPRECATE // get rid of sprintf security warnings on VS2005 #define HAVE_VISTA_HEADERS #endif ... and further down ... #ifdef HAVE_VISTA_HEADERS #include "Mmdeviceapi.h" #include "functiondiscoverykeys.h" #endif
I have written to the OpenAL development board advising them that not all of us have the new VISTA headers installed, and felt this type of 'option' should only be supplied through a define to the compiler, rather than hard coded as it is. So maybe, over time this problem will evaporate, but in this case I had to alter the code to read ...
#undef HAVE_VISTA_HEADERS
As previously stated, this OLD compiler is quite BROKEN, and due to its age, Microsoft will never provide any updates. It seems to treat certain structure members differently. Here is an example -
--------------------Configuration: SimGear - Win32 Release-------------------- Compiling... newbucket.cxx .\simgear/math/SGVec2.hxx(43) : error C2597: illegal reference to data member 'osg::Vec2f::_v' in a static member function .\simgear/math/SGVec2.hxx(46) : error C2597: illegal reference to data member 'osg::Vec2f::_v' in a static member function Error executing cl.exe.
This requires quite an amount of 'fiddling' with the code ;=(( The problem is made even more difficult by the fact that OSG uses 'extension less' header files, like just 'Vec2f', Vec2d, etc in OpenSceneGraph/include/osg. SOMETIMES, with quite MASSIVE changes in the CODE I have been able to compile SimGear, BUT THE RESULTANT LIBRARY WAS SO ERRANT THAT IT WAS NOT USEABLE ;=((
AT THIS POINT I AM GIVING UP ON TRYING TO COMPILE FLIGHTGEAR WITH MSVC6. IT JUST DOES NOT SEEM WORTH THE EFFORT!!!
I got through 22 of the Projects, and only baulked on SimGear just before FlightGear ...
But part of this exercise was to generate a DSW file, with a set of 24 or so DSP projects included. That is one single DSW/DSP load covers ALL the dependencies, and finally building FlightGear, as I have done in MSVC7 and MSVC8. It is intended that this COMBINE DSW/DSP build set would then be used to get a MSVC7.1 starting set of build files - unfortunately MSVC7.1 will NOT read MSVC8 build files, but it WILL read MSVC6 build files, and convert them to its own format. So most of the following is still completely relevant.
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.
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 ...
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 ...
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 vc8sln04.zip given below. After this setupfg.bat has run, I have a simpler set of WORK folders, containing the desired sources :-
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.
As stated above, here I am trying to use MSVC6 - each component, and finally FG could be loaded individually, and built separately, but I have created a single solution file (DSW), and set of MSVC6 project files (DSP), 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, the modified sources are also included in vc6chg01.zip. But you should first try the build WITHOUT these modified files. To aid in this, the source changes are in separate zip files, within the main zip. 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 vc8sln04.zip into your chosen 'work' folder, allowing an overwrite of the existing project files.
As well as the modified source zip file, this will also add a srccfg04.zip to the 'work' folder. This must also be unpacked, using the folder names ... Load fgfs\fgfs.dsw file in MSVC6, select either 'Debug' or 'Release' configuration and build ...
For example, in building from earlier version to develop this version, I found I had to delete few files, add few, and sometimes even changed source folder ... this type of ongoing change is 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 Microsoft Visual C++ 6.0 (MSVC6), is using the runtime library 'Multithreaded DLL' (/MD), and 'Multithreaded Debug DLL' (/MDd)! When you create a new project in MSVC6 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.
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 the sound files installed, then it will refuse to do anything until these are deleted ...
Now you are ready to run flightgear. There are a number of batch files in 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 ...
1.<none> - Set of WIN32 runtime binaries from MSVC6 is NOT available, since I was unable to complete the compile ;=((
2. vc6dsw01.zip - Work in Progress, and this is the MOST RECENT single DSW, with 24 DSP project files. Since the build FAILED on simgear and flightgear the progress STOPPED - MD5 = cab8e3eeab78926f1b200e759bedd838 - contents -
Length Size Ratio Date Time Name ------ ----- ----- ---- ---- ---- 10146 786 93% 21/04/2007 16:07 fgfs\fgfs.dsw 2934 956 68% 05/06/2006 14:29 OpenAL\OpenAL-Windows\Alc\ALc.dsp 2934 956 68% 05/06/2006 14:29 OpenAL\OpenAL-Windows\Alu\ALu.dsp 28619 3159 89% 21/04/2007 14:12 OpenSceneGraph\VisualStudio\osg\osg.dsp 11070 1878 84% 21/04/2007 14:14 OpenSceneGraph\VisualStudio\osgDB\osgDB.dsp 13527 2080 85% 21/04/2007 14:16 OpenSceneGraph\VisualStudio\osgUtil\osgUtil.dsp 75983 7077 91% 21/04/2007 13:06 FlightGear\FlightGear.dsp 5867 1404 77% 21/04/2007 16:07 OpenAL\OpenAL-Windows\OpenAL32\OpenAL32.dsp 8297 1557 82% 21/04/2007 14:31 OpenThreads\win32_src\OpenThreads.dsp 4751 1257 74% 21/04/2007 13:54 OpenAL\OpenAL-Windows\Router\Router.dsp 14487 2247 85% 21/04/2007 18:40 SimGear\source\SimGear.dsp 4215 1051 76% 21/04/2007 13:54 fgfs\fgfs.dsp 3295 971 71% 09/12/2006 19:25 PLIB\src\fnt\fnt.dsp 5371 1207 78% 21/04/2007 13:54 freeglut\freeglut_static.dsp 3447 978 72% 09/12/2006 19:25 PLIB\src\js\js.dsp 4213 1057 75% 09/12/2006 19:25 PLIB\src\net\net.dsp 8389 1617 81% 21/04/2007 16:07 OpenSceneGraph\VisualStudio\osgPlugins\ac3d\ac3d.dsp 8071 1596 81% 21/04/2007 16:07 OpenSceneGraph\VisualStudio\osgPlugins\rgb\rgb.dsp 4452 1273 72% 21/04/2007 13:54 pthreads\pthread.dsp 4301 1097 75% 09/12/2006 19:25 PLIB\src\puAux\puAux.dsp 5378 1192 78% 09/12/2006 19:25 PLIB\src\pui\pui.dsp 3322 970 71% 09/12/2006 19:25 PLIB\src\sg\sg.dsp 9572 1512 85% 09/12/2006 19:25 PLIB\src\ssg\ssg.dsp 3541 981 73% 09/12/2006 19:25 PLIB\src\util\ul.dsp 17360 1995 89% 04/10/2004 06:00 zlib-1.2.3\projects\visualc6\zlib.dsp ------- ------- --- ------- 263542 40854 85% 25
You can also 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.
This is a somewhat abbreviated version ;=))
If this is your first run, you may have to 'Unblock' the net communications, depending 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 ...
Since this is NOT an automated build system, and many of the projects are very active, the DSP 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 a Mar 30,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.
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.
Linking... Embedding manifest... Build Time 6:20 Build log was saved at "file://c:\FG\14\FlightGear\Release\BuildLog.htm" FlightGear - 0 error(s), 251 warning(s) ========== Build: 24 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
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 ...
Of course, in the above link, I am IGNORING the 251 warnings!!! Hopefully NOT at my peril ;=)).
MSVC6 Work In Progress
Happy SIM flying ...
Geoff R. McLane
date: 20070421
EOP - fgfs-035.htm