Preamble Folders Order Builds freeglut OpenAL alut PLIB zlib pthreads OpenSceneGraph OpenThreads Producer OSG SimGear FlightGear download end
My first attempt with FlightGear OSG had some success, and some failure. You can read ALL the gory DETAIL on the previous page. This NEW attempt commenced 20 November, 2006. The OSG implementation is still undergoing changes and fixes, so this is still somewhat of a work-in-progress ...
This build, with Microsoft Visual C++ 2005 Express Edition (MSVC8), is using the runtime library 'Multithreaded DLL' (/MD), and 'Multithreaded Debug DLL' (/MDd)! When you create a new project in MSVC8 this is the default, but many prerequisite projects use /MT-/MTd. It is VERY IMPORTANT that the runtime of the prerequisites and the final FlightGear build all use the SAME runtime, or else there will be 'conflicts' in the LINK.
Where possible each of the sources used is the latest update of the cvs or svn source, where possible, or else the latest tarball available. I choose NOT to build in the download, updated folders, but xcopy the source to a new folder. This is mainly because I have the disk space, and, on subsequent updates, I like to review what has been changed before including it. Also this allows me to make local modifications, and be able to do a local diff of the sources.
Also, in some cases, when making the xcopy I try to reduce the folder depth, but this entirely depends on the CVS, SVN or tarball original folder. In this case, my 'root' directory is C:/FG/FG0910-7, and in that directory I have the following folder structure -
It also shows the current list a prerequisites, and these are the links, (and source indication) - freeglut (cvs), OpenAL (svn), OpenSceneGraph (cvs), OpenThreads (cvs), PLIB (svn), Producer (cvs), pthreads (cvs), SimGear (cvs), zlib (tarball) and OpenGL (NA) ... Although different links have been given for OpenThreads and Producer, these can also be obtained through the OpenSceneGraph link. And although a link has been provided for OpenGL, it is a prerequisite, this comes pre-installed in Windows XP, thus there is no folder for this.
The folders 'bin', 'data', and 'fgfs' are a little special -
bin - is where I run FlightGear.exe from. It contains the required shared
libraries (DLLs) to run FG ...
data - is an xcopy of the cvs updated folder. The runtime DATA for FG ...
fgfs - contains an all-in-one solution file, that build ALL the required sources
The order of the build is important, since some of these prerequisites depend on others. Naturally FlightGear MUST be last, since it depends on them all, and generally SimGear should be second last, since it also depends on each of the others. Generally I try to use the static library version of the prerequisite, since this saves the hassle of installing the shared libraries (DLL), but in this build only freeglut, PLIB, SimGear and zlib are STATIC library builds. The others, OpenAL, OpenSceneGraph, OpenThreads, Producer, and pthreads are all shared libraries (DLL).
After xcopying the updated source, loading, and converting freeglut.dsw to solution files it shows two(2) projects - freeglut - DLL, and freeglut_static - static library. Checking the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library I note they presently default to /MT-/MTd, so I change 2 X 2 configuration to /MD-/MDd ... Take care with this change, as mixing Debug and Release can also cause later LINK problems ...
To avoid a VERY UGLY 'depreciation' warning, I also add _CRT_SECURE_NO_DEPRECATE to Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, after adding a ';' separator ...
Generally, I use Build -> Batch Build ... clicking [ Select All ], and [ Build ], or even [ REBUILD ] ... this generates four (4) libraries (LIB) - 2 for the Shared libraries (DLL) and two (2) STATIC libraries, and two (2) Shared Libraries (DLL), which, in this case I may not use -
Shared Libraries (DLL) Directory of C:\FG\FG0910-7\freeglut\Release 20/11/2006 14:10 32,228 freeglut.lib 20/11/2006 14:10 192,512 freeglut.dll Directory of C:\FG\FG0910-7\freeglut\Debug 20/11/2006 14:04 32,228 freeglut.lib 20/11/2006 14:10 311,296 freeglut.dll Static Libraries Directory of C:\FG\FG0910-7\freeglut\DebugStatic 20/11/2006 14:10 1,111,060 freeglut_static.lib Directory of C:\FG\FG0910-7\freeglut\ReleaseStatic 20/11/2006 14:10 505,626 freeglut_static.lib Directory of C:\FG\FG0910-7\freeglut\Release
Ready for the link ...
OpenAL is two(2) separate, but related projects, OpenAL, and alut - BOTH must be built. And you have a choice of using the MSVC6 dsw/dsp build files, and converting them, or the MSVC8 sln/vcproj files ... In this case I choose the MSVC8 files ...
Loading the OpenAL.sln file in MSVC8 shows it consists of four (4) projects, ALc, ALu, OpenAL, and Router. After correcting the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library to my chosen /MD & /MDd (Release & Debug), and opening the Batch Build I note there are sixteen (16) configurations, half of them related to the fast arriving 64-bit ... for the moment, I select all, and de-select the 8 x64 items ...
But on my first batch build, two (2) FAIL - missing an include header - Mmdeviceapi.h ... checking in the alc.cpp source I note this is under a define - HAVE_VISTA_HEADERS! ... the top of apl.cpp shows this is DEFINED unconditionally, just after _CRT_SECURE_NO_DEPRECATE, which I do want defined ... so I glibly comment out the 'have vista', like -
// #define HAVE_VISTA_HEADERS
But still find another missing <atlconv.h> header ... In this case I change the line -
#ifndef __MINGW32__
to
#if ( !defined(__MINGW32__) && !defined( _MSC_VER ))
and it compiles ... This yields 2X2 (4) Shared Libraries (DLLs), and 2x4 (8) libraries, as follows -
Dynamic Link Libraries Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Debug 20/11/2006 14:30 143,360 wrap_oal.dll Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Release 20/11/2006 14:31 86,016 wrap_oal.dll Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Debug 20/11/2006 14:49 77,824 OpenAL32.dll Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Release 21/11/2006 11:17 49,152 OpenAL32.dll Libraries Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alc\Debug 20/11/2006 14:30 142,238 ALc.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alc\Release 20/11/2006 14:30 49,814 ALc.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alu\Debug 20/11/2006 14:30 44,190 ALu.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Alu\Release 20/11/2006 14:30 11,344 ALu.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Debug 20/11/2006 14:30 20,328 wrap_oal.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\OpenAL32\Release 20/11/2006 14:31 20,328 wrap_oal.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Debug 20/11/2006 14:49 20,004 OpenAL32.lib Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Windows\Router\Release 21/11/2006 11:17 20,004 OpenAL32.lib
This is ready for the LINK, but I must also deal with 'installing' the DLLs in some appropriate place.
There is a alut.dsw, and an alut.sln. I load the MSVC7 'solution' file in MSVC8, and convert. It shows three (3) projects, alut, hello_world, and playfile. I check each of the 6 configurations, but find they have already been set to /MD & /MDd.
My first attempt at running the Batch Build for the 6 configurations shows an interesting error -
c:\fg\fg0910-7\openal\alut\src\alutInternal.h(24) : fatal error C1189: #error : Do not know sized types on this platform
It seems the WIN32 port has not yet reached the cvs source. At the top of the alutInternal.h file, I note a define like -
#if HAVE_CONFIG_H #include "config.h" #endif
But, as is usual, there is no config.h file! In the *nix would this file is auto-generated by the auto-make tools they use, but in WIN32 we have to manually create one. As you will see later in the FlightGear project, there is no actual config.h, but there is a config.h-msvc6.in, and config.h-msvc8 which provides the fairly constant information in WIN32 ... I this case I create a alut/src/config.h, with a single define, HAVE___INT8, and add HAVE_CONFIG_H to the Project -> Properties -> Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions ... as follows
// config.h - constants for MSVC compile - geoff mclane - Nov, 2006 #ifndef __config_h__ #define __config_h__ #ifndef HAVE___INT8 #define HAVE___INT8 1 #endif // HAVE__INT8 #define _CRT_SECURE_NO_DEPRECATE #endif // #ifndef __config_h__ // eof - config.h
Note at the same time I suppressed the UGLY 'depreciate' warning. Then it can not locate the header alc.h ... but it exists in two (2) locations -
Directory of C:\FG\FG0910-7\OpenAL\include\AL 01/11/2006 16:17 8,124 alc.h Directory of C:\FG\FG0910-7\OpenAL\OpenAL-Sample\common\include\AL 01/11/2006 16:19 8,124 alc.h
Checking the alut Property Pages -> Configuration Properties -> C/C++ ->
General -> Additional Include Directories I note it contains -
C:\Program Files\OpenAL 1.1 with EFX SDK\include;..\..\..\include
which I adjust to -
..\..\..\include;..\..\..\..\include\AL
Like wise for the LINK, I have to adjust the Property Pages -> Configurations
Properties -> Linker -> General -> Additional Library Directories to -
..\..\..\..\OpenAL-Windows\Router\$(IntDir)
Of course, the above adjustments apply to all projects, all configurations 3 x 2 (6) changes ... the use of the $(IntDir) saves changing from Debug to Release in each case ...
This succeeds in producing 2 x 2 DLL/LIB shared library pairs - the LIB is to resolve the 'imports' during the link, and the DLL is needed at runtime -
Directory of C:\FG\FG0910-7\OpenAL\alut\admin\VisualStudioDotNET\alut\Debug 21/11/2006 12:40 5,922 alut.lib 21/11/2006 12:40 73,728 alut.dll Directory of C:\FG\FG0910-7\OpenAL\alut\admin\VisualStudioDotNET\alut\Release 21/11/2006 12:40 5,922 alut.lib 21/11/2006 12:40 24,576 alut.dll
These are ready for the LINK ...
After doing an xcopy of the update svn source to my work folder, load the PLIB.dsw, and convert there are thirteen (13) projects - fnt, js, net, plib, psl, puAux, pui, pw, sg, sl, ssg, ssgAux and ul. And each of the twelve x 2 (24) - plib is only the glue to bind them all - have to be changed from their default /MT & /MTd to my choice, /MD & /MDd - a BIG click, click, click ... exercise.
I always threaten to write my self a Perl script to do this ;=)) I have started on it, but it is not yet complete. At the same time I add the PESKY - _CRT_SECURE_NO_DEPRECATE to each ... but the Batch Build produces a few errors ...
In ssgSaveAC.cxx, ssgLoadMDL_BGLTexture.cxx and ssgParser.cxx I change the lines -
#ifdef UL_BB to #if (defined( UL_BB ) || defined( UL_MSVC ))
One line in netChat.cxx from
char* ptr = strstr(data,needle); to char* ptr = (char *)strstr(data,needle);
There are a few UGLY 'depreciation' and some other warnings, which I ignore. I end up with 2 x 12 (24) static libraries -
Directory of C:\FG\FG0910-7\PLIB 21/11/2006 13:37 233,368 fnt.lib 21/11/2006 13:37 232,222 fnt_d.lib 21/11/2006 13:37 16,542 js.lib 21/11/2006 13:37 156,738 js_d.lib 21/11/2006 13:37 70,450 net.lib 21/11/2006 13:37 267,356 net_d.lib 21/11/2006 13:37 580,674 psl.lib 21/11/2006 13:37 644,230 psl_d.lib 21/11/2006 13:37 1,242,610 puAux.lib 21/11/2006 13:36 1,288,338 puAux_d.lib 21/11/2006 13:36 1,105,292 pui.lib 21/11/2006 13:36 1,130,740 pui_d.lib 21/11/2006 13:36 17,942 pw.lib 21/11/2006 13:36 56,270 pw_d.lib 21/11/2006 13:36 380,856 sg.lib 21/11/2006 13:36 402,364 sg_d.lib 21/11/2006 13:36 544,488 sl.lib 21/11/2006 13:36 507,350 sl_d.lib 21/11/2006 13:35 5,502,922 ssg.lib 21/11/2006 13:34 1,171,810 ssgAux.lib 21/11/2006 13:34 1,214,746 ssgAux_d.lib 21/11/2006 13:36 5,478,616 ssg_d.lib 21/11/2006 13:34 166,388 ul.lib 21/11/2006 13:34 167,964 ul_d.lib
I will not need them ALL for the FlightGear project, but these are ready for the LINK ...
Although there are three (3) solution (SLN) files, I have had some trouble linking with the 'static' library using these, so in this case I use the zlib.dsw, and convert it in MSVC8 ... this has three (3) projects - example, minigzip, and zlib. I only want the static zlib, so unload the other two projects.
The zlib project has 2 x 2 x 2 (8) configurations. 2 x 2 (4) ASM configurations, which requires Microsoft Assembler (ML.EXE) installed. Although I do have this installed, I choose not to use these. The remaining four (4) are Debug and Release of the shared (DLL) and static libraries. In the Batch Build I only select the two static libraries, LIB Debug, and LIB Release. On checking the runtime is already set to /MD and /MDd ... and OF COURSE, I remember to add - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ...
This quickly builds me two (2) STATIC libraries -
Directory of C:\FG\FG0910-7\zlib-1.2.3\projects\visualc6\Win32_LIB_Debug 21/11/2006 13:57 255,574 zlibd.lib Directory of C:\FG\FG0910-7\zlib-1.2.3\projects\visualc6\Win32_LIB_Release 21/11/2006 13:57 104,542 zlib.lib
These are ready for the LINK ...
In SimGear, simgear/threads/SGThreads.cxx, and in FlightGear ENABLE_THREADS is an OPTION ... SimGear and FlightGear can be built and run WITHOUT using pthreads ... but in this build, I have chosen to include it ... and pthreads should NOT be confused with OpenThreads, which IS a prerequisite of OpenSceneGraph ...
Loading and converting the pthreads.dsw, there is only one (1) project, with the usual Debug and Release configurations. I check that the Code Generation -> Runtime Library is my desired /MD and /MDd, and add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ... and in Batch Build, [ Select All ] and [ Build ] ...
After the build, I can only find one (1) DLL/LIB pair. This is because the Linker output has been set to the SAME NAME! I change the Debug output to pthreadVC2_d.dll, and the export library to pthreadVC2_d, and then I get 2 x 2 DLL/LIB pairs ...
Directory of C:\FG\FG0910-7\pthreads 21/11/2006 14:49 29,056 pthreadVC2.lib 21/11/2006 14:48 29,386 pthreadVC2_d.lib 21/11/2006 14:49 30,208 pthreadVC2.dll 21/11/2006 14:48 94,208 pthreadVC2_d.dll
Not that I intend to use the Debug version, but it seems to me 'confusing' when all outputs are directed to the same file. These are now ready for the LINK ...
As indicated, OpenSceneGraph has a number of prerequisites - OpenThreads, and Producer, more or less come with OpenSceneGraph, and should be built BEFORE OpenSceneGraph. But if you want to build ALL the plugins of OpenSceneGraph then there are a number of OTHER prerequisites, like jpeg, gdal, gif, tiff, png, ... (the links given are just guesses!) to name a few ...
Also I have the option of trying the latest CVS update, but in this period of transition, if this is used, a number of patches have to be applied. Or one can use the modified source from Olaf/Matias, which seems based on an earlier stable release of OpenSceneGraph ... I opt to try the CVS source first ...
I load and convert the Win2_src/OpenThreads.dsw. This shows there is one project with 2 x 2, 4 configurations - static and shared - I have tried the static, but, like others have indicated, ran into link problems, so am going to use the shared (DLL) configurations ... I check that the Release and Debug configuration are set to runtime /MD and /MDd ...
I add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ... and in the Batch Build select only Release and Debug, and leave the Release Static and Debug Static unchecked, and [ Build ] ... I am rewarded with 2 x 2 LIB/DLL pairs -
Directory of C:\FG\FG0910-7\OpenThreads\bin\win32 21/11/2006 15:02 18,944 OpenThreadsWin32.dll 21/11/2006 15:02 90,112 OpenThreadsWin32d.dll Directory of C:\FG\FG0910-7\OpenThreads\lib\win32 21/11/2006 15:02 22,842 OpenThreadsWin32.lib 21/11/2006 15:02 22,908 OpenThreadsWin32d.lib
These are now ready for the LINK ...
While Producer has a MSVC6 Producer.dsw file, I choose to load and convert the MSVC7 Producer.sln file ...
This shows there is one project with 2 x 2, 4 configurations - static and shared - I have tried the static, but, like others have indicated, ran into link problems, so am going to use the shared (DLL) configurations ... I check that the Release and Debug configuration are set to runtime /MD and /MDd ...
I add the UGLY - _CRT_SECURE_NO_DEPRECATE - to the Preprocessor Definitions ... and in the Batch Build select only Release and Debug, and leave the Release Static and Debug Static unchecked, and [ Build ] ... I am rewarded with 2 x 2 LIB/DLL pairs - I do not a warning, which I ignore -
Directory of C:\FG\FG0910-7\Producer\bin\win32 21/11/2006 15:13 270,336 Producer.dll 21/11/2006 15:13 753,664 Producerd.dll Directory of C:\FG\FG0910-7\Producer\lib\win32 21/11/2006 15:13 254,208 Producer.lib 21/11/2006 15:13 254,872 Producerd.lib
These are now ready for the LINK ...
I open and convert the VisualStudio/OpenSceneGraph.dsw. YOW! This shows a massive one hundred and sixty three (163) projects, and as with the above prerequisites there are four (4) configuration, Release, Release Static, Debug, and Debug Static ...
If ever there was a NEED to have a script to check the runtime, and UGLY 'depreciation' define it would be NOW ;=)) But a check of a 'few' projects shows /MD and /MDd, and the PESKY _CRT_SECURE_NO_DEPRECATE has already been added ... but anyway, I decide it is time to get such a script running ... I need a rest from C++/MSVC, and coding a perl seems a welcome relief ...
OK, did that ;=)) this is a small synopsis in the head of the Perl file - later I will publish the final version - this is a link to an earlier, incomplete effort which only changed to the /MT (or /MTd) runtime ...
#!/Perl -w # adjrt02.pl - geoff mclane # AIM: Given a SOLUTION (SLN) file, extract all projects # Check and report RUNTIME setting - differentiate Debug/Release / static or not # IFF $write_changes set, rename the file to .BAK, and write new vcproj file, # else, just REPORT what would be changed if it was ON. # OTHER USER OPTIONS # IFF $UseMD is set, will adjust to /MD[d], else /MT[d] # IFF $FixIgnore is set, will remove any IGNORE libraries # IFF $FixStatic is set, will ALSO adjust those configuration that contain the word STATIC # IFF $FixPrep1 is set, will ENSURE _CRT_SECURE_NO_DEPRECATE is in Preprocessor defines
I try the Debug configuration build - F7 - it takes quite some time to get through the 163 projects ... of course a number of items build fine, but there are zillions of errors ;=(). I am not so sure I like the new multi-threading of MSVC8 - I did not see this on an earlier version of MSVC8 I tried, or maybe it is only enabled on dual core, or multiprocessors - who knows ...
Now it commences each output line with a number representing the particular
project ... but, for example project 6 went on for ages - other project counts
of over 100 were showing at the same time ... it seems you must later SORT this
output, if you want to read project by project ... the final out of 22,037 lines
is -
163>osgWrapper osgUtil - 488 error(s), 262 warning(s)
Build: 52 succeeded, 111 failed, 0 up-to-date, 0 skipped
showing more that more than twice as many FAILED, as succeeded ;=((
A large number of errors are of the form -
103>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in
MSVCRTD.lib(cinitexe.obj)
which is a clear indication of a RUNTIME conflict. Maybe I should let my Perl
script change everything to /MD or /MDd? Especially since during this trial I
had left the (default) configuration to 'Debug Static' ... I change this to
'Debug' and give it another run - F7 ... that turned around the odds at least -
Build: 141 succeeded, 21 failed, 1 up-to-date, 0 skipped, and there were
no LNK2005 conflicts ;=))
Some of the missing include headers (Error C1083) I can fix, like GL/glut.h (osgsimpleviewerGLUT.cpp, osgGLUTsimple.cpp, osgGLUTkeyboardmouse.cpp, ...), zlib.h (ReaderWriterPNG.cpp) - this is just adjusting the Additional Include Directories for those projects ...
But other, like gdal_priv.h (DataSet.cpp, ReaderWriterGDAL.cpp, ...), tiffio.h (ReaderWriterTIFF.cpp), jpeglib.h (ReaderWriterJPEG.cpp), gif_lib.h (ReaderWriterGIF.cpp), ft2build.h (FreeTypeFont.h), dom/domSource.h (domSourceReader.cpp), dae.h (daeReader.h), qtimer.h/QtCore/QTimer (osgsimpleviewerQT3.cpp, osgsimpleviewerQT4.cpp), SDL.h (osgsimpleviewerSDL.cpp), FL/Fl.H (osgsimpleviewerFLTK.cpp), ..., require sources that I do not have ...
Of the twenty one (21) that failed, this is my initial decision tree - EXCLUDE in this case means unload the project, and TRY FIX means exactly that. There is no guarantee that this first fix will not lead to other errors ...
So NONE of the five (5) TRY FIX come to the party, but I do succeed in
getting 142 built -
Build: 0 succeeded, 0 failed, 142 up-to-date, 0 skipped
and I head out on the Release build - change configuration to Release, and build
(F7) ... I timed it, and the compile took about
1/2 an hour ... but I only got 140 -
Build: 140 succeeded, 2 failed, 0 up-to-date, 0 skipped
but it must be something to do with the build ORDER, since another F7 yielded
the other two (2) -
Build: 2 succeeded, 0 failed, 140 up-to-date, 0 skipped
I cleaned away the errant Debug Static run, and in bin/Win32 I have 82 x 2 (164) executables, 60 x 2 (120) shared libraries (DLL), and in lib/Win32 13 x 2 libraries (LIB) ... all ready for the LINK ...
I have a perl script, am2dsp7.pl, which reads all the makefile.am files, and build a SimGear.[DSW/DSP] pair of files, taking configuration from an am2dsp7.cfg file ...
I load and convert the SimGear.DSW file, and despite all my babbling about RUNTIME, I FORGET to check the runtime. Of course, this does NOT show up until you get to linking the static library into FlightGear. Anyway, I subsequently adjust it to /MD and /MDd and build the library again.
Eventually I end up with two (2) STATIC libraries -
Directory of C:\FG0910-5\SimGear\Debug 09/11/2006 18:41 39,554,894 SimGear.lib Directory of C:\FG0910-5\SimGear\Release 09/11/2006 18:38 14,043,870 SimGear.lib
These are now ready for the LINK ...
Using my am2dsp7.pl, I overwrite the FlightGear.[DSW/DSP] files with new ones ...
I load and convert the SimGear.DSW file ... the compile proceeds fine ... lot of warnings, which I ignore ... but again, despite all my babbling about getting RUNTIME right, I end up with lots of errors of the form -
1>msvcprtd.lib(MSVCP80D.dll) : error LNK2005: "public: class
std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>
> & __thiscall std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::operator=(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > const &)"
(??4?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z)
already defined in acmodel.obj, and
1>MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _sprintf already defined in
LIBCMTD.lib(sprintf.obj), which, of course ends with
1>Build log was saved at "file://c:\FG\FG0910-7\FlightGear\Debug\BuildLog.htm"
1>FlightGear - 180 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Some project is NOT RIGHT? Back through them one-by-one - even the unused! ... ALc, ALu, OpenAL, Router, alut, Freeglut, Freeglut static, PLIB - fnt, js, net, psl, puAux, pui, pw, sg, sl, ssg, ssgAux, ul, pthreads, OpenThreads, Producer, OSG - Core - osg, osgDB, osgFX, osgGA, osgIntrospection, osgParticle, osgProducer, osgShadow, osgSim, osgText, osgUtil, osgViewer, osgPlugin - 3dc, 3ds, ac3d, bmp, bsp, dds, directx, dw, dxf, ESRI, fit, geo, hdr, ive, logo, lwo, lws, ... this got too boring, so ran my Perl script, and changed EVERYTHING to MD/MDd, even the 'static' versions, which I am not presently building ... zlib ... AHA, had made an error with ZLIB ...
I tried something I have tried before, and failed - that is using the zlib 'solution' build - but when I link FlightGear top zlibstat.lib, I get a big bunch of UNRESOLVED, obviously ZLIB calls, so I stick to loading and converting the zlib.dsw to MSVC8, and using the static libraries built, namely, zlibd.lib and zlib.lib in their respective $(IntDir) - 'IntDir' is a macro for Debug and Release folders respectively ....
24-11-2006 - Get both DEBUG, and Release version LINKED ...
Directory of C:\FG\FG0910-7\FlightGear\Debug 24/11/2006 11:48 11,788,288 FlightGear.exe Directory of C:\FG\FG0910-7\FlightGear\Release 24/11/2006 11:58 3,772,416 FlightGear.exe
Now to try to RUN it ... excitement rains ... BUT, how to 'install' the DLLs???
From Microsoft -
http://msdn2.microsoft.com/en-us/library/7d83bc18(vs.80).aspx -
I can see that the FIRST search for a shared library (DLL), is the path of the
executable image (binary), so this gives me a chance to put everything in say a
'bin' folder, the main FlightGear EXE and all the prerequisite DLLs ...
This excludes OpenAL - openal32.dll, alut.dll and wrap_oal.dll - from past
experience I find these need to be in the 'system' folder - this is the folder
returned by GetSystemDirectory(...), which on my system returns -
C:\WINDOWS\system32
so this is where I copy these particular files ... this is a
batch file I
use, which includes a DELETE command ...
This single folder approach works great for the Release configuration ... Debug get more complicated because some shared libraries have the SAME NAME. It is probably better you create a separate sub-folder for that, and to use the debug versions then I always copy all the library build components. Like for pthreads, that would mean -
Directory of C:\FG\FG0910-7\pthreads 21/11/2006 14:49 30,208 pthreadVC2.dll 21/11/2006 14:41 403 pthreadVC2.dll.embed.manifest 21/11/2006 14:41 468 pthreadVC2.dll.embed.manifest.res 21/11/2006 14:49 380 pthreadVC2.dll.intermediate.manifest 21/11/2006 14:49 16,755 pthreadVC2.exp 21/11/2006 14:49 29,056 pthreadVC2.lib 21/11/2006 14:43 40,383 pthreadVC2.map 21/11/2006 14:43 486,400 pthreadVC2.pdb
.Actually only the DLL and PDB (Program Data Base) are really necessary ...
To facilitate this process, I change FlightGear -> Property Pages ->
Configuration: Release -> Configuration Properties -> Linker -> General ->
Output File to -
..\bin\flightgear.exe
and the Debug to
..\bin\flightgeard.exe
Note the 'd', to denote Debug ... On the same properties page I usually change
-> Enable Incremental Linking to 'Default', to avoid some linker warnings ...
If you want to 'discover' which DLLs are missing, then you can try running the Debug version - F5 - ... find and copy that DLL to bin ... but this will miss the needed osg Plugins DLLs ... like osgdb_ac[d].dll, and osgdb_rgb[d].dll ...
And it is around this time I create the 'data' directory, to hold an xcopy of
the recently cvs updated C:/FGCVS/FlightGear/data folder ... add add the command
argument
--fg-root=..\data
and set the Working Directory to
C:\FG\FG0910-7\bin
I'm ready for my first flight ... AND IT FLIES, with sound ...
*** IT FLIES! IT FLIES! IT FLIES! ***
The frame rate is a dreadful 5 fps with this file full of debug information ... so I only do a short night take off and landing ... only a few minutes ... the first 'external' view, v key-in, is great at night, with all the lights ... I set up a batch file to run from WITHIN the 'bin' directory - with a simple line ...
FlightGear --fg-root=..\data --fog-disable --timeofday=noon
On the first run of flightgear, I usually get the security alert -
I nearly always click [ Unblock ] ... I think it is just the PLIB net.lib kicking windows sockets into gear ...
I take off, and begin a climb to about 1500 feet, and do a quiet left 180 turn, to head out into the bay. I head north until I am about within the Oakland, I think it is, approach path, and adjust for a landing ... but regrettably by the time I was down to about 600 feet, BANG, the dread XP dialog -
On the next flight I was able to land, taxi, turn, and take off before the BIG BANG occurred ;=))
But the little bit of flying was 'fun' ... saw frame rates 90 fps, even about 115 fps at one time ... happy with everything, except this segfault as it seems to be called in most *nix systems ... this is with the cvs version, updated as of 23 November, 2006 ... GREAT WORK ... keep it FLYING ;=))
Update 22/12/2006: In dynamic cvs/svn sources, this single 'solution' file needs frequent updates to keep track of the changes in the source. The dozen or so, 'simple' steps to use this single 'solution' are as follows -
| Date | Download | Description | Size | MD5 Digest |
|---|---|---|---|---|
| 22/12/2006 | vc8sln03.zip | Full MSVC8 solution set, including fgfs/fgfs.sln to do ALL prerequisites, and EXE as ONE solution, 25 projects |
85,039 |
243b85b0cd43329b2292d5e7c8ceb42d |
| 22/12/2006 | fgvc8rt03.zip | Full runtime set - EXE and DLLS to run FlightGear in a Windows XP machine. |
2,450,576 |
f492ef83cf0c0804e6b8b6374211bd11 |
Note, these downloads are hosted on another server. If clicking on the download link does not start the download, try a Right Mouse Click and choose 'Save Target As...' in the context menu. I have left my first and second attempts below, since most of the explanations are still valid, but are now fully replaced with this updated version ... The runtime zip is much smaller than previous, since it now only contains the Release configuration ...
Update 15/12/2006: This single 'solution' file, and a runtime zip containing all the prerequisite EXE and DLLs worked so well I did it all a second time, hopefully simplifying it even further. Essentially, you should be able to download the runtime zip, fgvc8rt02.zip, unzip it into a folder, deal with OpenAL if you have not previously installed this, download the FlightGear BASE data, and you should be able to run FlightGear in an XP machine very easily.
Also I have reduced the number of VCPROJ files in the vc8sln02.zip, and separated the files that may need to be changed, and the configuration files into separate zips, within this zip. The zip also contains a README.fgfs which explains all the components ... Note, only the Release and Debug configurations are fully validated.
| Date | Download | Description | Size | MD5 Digest |
|---|---|---|---|---|
| 10/12/2006 | fgvc8rt02.zip | Full runtime set - EXE and DLLS to run FlightGear in a Windows XP machine. |
8,041,119 |
64cec8e0f48c4c365ebf0b73758c7d56 |
| 15/12/2006 | vc8sln02.zip | Full MSVC8 solution set, including fgfs/fgfs.sln to do ALL prerequisites, and EXE as ONE solution, 25 projects |
119,610 |
5064d025944bf7f1cff5379b1ae05150 |
Note, these downloads are hosted on another server. I have left my first attempt below, since most of the explanations are still valid, but it is now fully replaced with this updated version ...
This is much easier if you use the SAME directory structure as shown above. The following zips contain -
ZIP vc8sln01.zip - contains ALL the SLN/vcproj files used in preparing this page, including a SPECIAL fgfs.sln, which will build it ALL - when loaded into MSVC8 it will show 24 projects - all the prerequisites, and the final FlightGear.exe ... only the configurations 'Release' and 'Debug' are valid. The other configurations may not function.
ZIP fgvc8rt01.zip - contains the binary runtime for WIN32. That is the FlightGear.exe, and various shared libraries (DLLs) to execute the application. Theoretically, you could unpack this into a FOLDER, deal with installing the OpenAL DLLs, in the OpenAL folder, then FlightGear.exe should run ... I have not tried FlightGeard.exe ...
| Download | Description | MD5 Digest |
|---|---|---|
| vc8sln01.zip | Full set of solution (MSVC8) build files. The single fgfs.sln will build ALL the prerequisite cvs/svn sources, then FG | MD5 (vc8sln01.zip) = ff2ef9af5423bf10ac24db6692892ead |
| fgvc8rt01.zip | Full runtime binary set - FlightGear.exe, and DLLs. | MD5 (fgvc8rt01.zip) = 1e1debdce2630fdf933c5dbc4b1059b9 |
USE vc8sln01.zip - As a first step, you should update the cvs/svn source. Create a work folder, and add all the above folders as subdirectories ... xcopy the CVS/SVN sources into each of the folders ... unpack vc8sln01.zip into your work folder, overwriting all the existing *.sln, *.vcproj files ... it will write a simgear/simgear/simgear_config.h, flightgear/src/include/config.h, and an alut config.h ... load fgfs.sln in MSVC8 ... this should show some 25 projects ...
Select the configuration called 'Release', out of the number of configurations shown - on load it seems to default to 'Debug Static", and this has NOT been tried or tested ... the following image shows the available configurations -
Select 'Release', and push F7 (build) ... go away and have some coffee ... it takes a while to do its thing ... about 15-20 minutes per configuration on my fast machine ... the final part of the output is -
... just the last few lines, of some 1,569 lines ... Generating Code... Linking... Embedding manifest... Build log was saved at "file://c:\FG\FG0910-8\FlightGear\Release\BuildLog.htm" FlightGear - 0 error(s), 265 warning(s) ========== Build: 25 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
WARNING: This single solution file, as good as it sounds, does NOT always functions as 'advertised'. While I have TRIED to get all the dependencies correct, sometimes I have to choose, and amend Menu -> Tools -> Options ... -> Projects and Solutions -> Build and Run -> maximum number of parallel project build from the default 4 to 1 ... but it should work without this change ...
But remember, all the prerequisite project each has their own 'solution' file, and this can be loaded to build, or rebuild a particular prerequisite ...
USE fgvc8rt01.zip - Create a work folder ... unzip all, using folder names ... deal with installing the OpenAL shared libraries (DLLs) ... Download, and update the base flightgear data source ... run FlightGear.exe with an appropriate command line, which MUST include --fg-root=<your data folder> at least ...
This zip contains the following files -
Zip file: fgvc8rt01.zip
Length Size Ratio Date Time Name
3772416 1500436 61% 24/11/2006 14:32 FlightGear.exe
11788288 3095163 74% 24/11/2006 14:32 FlightGeard.exe
26512080 5353178 80% 24/11/2006 14:32 FlightGeard.ilk
0 0 0% 25/11/2006 13:21 OpenAL\
24576 16427 34% 21/11/2006 12:40 OpenAL\alut.dll
49152 16035 68% 21/11/2006 11:17 OpenAL\OpenAL32.dll
1014 581 43% 25/11/2006 13:33 OpenAL\README.openal
473 226 53% 25/11/2006 13:20 OpenAL\upd.bat
544 241 56% 25/11/2006 13:17 OpenAL\update.mak
86016 36573 58% 20/11/2006 14:31 OpenAL\wrap_oal.dll
18944 8756 54% 21/11/2006 15:02 OpenThreadsWin32.dll
90112 17198 81% 21/11/2006 15:02 OpenThreadsWin32d.dll
1253376 432122 66% 22/11/2006 17:37 osg.dll
4272128 1085376 75% 22/11/2006 17:01 osgd.dll
262144 91205 66% 22/11/2006 17:38 osgDB.dll
1052672 260765 76% 22/11/2006 17:02 osgDBd.dll
147456 50551 66% 22/11/2006 17:47 osgdb_ac.dll
581632 135747 77% 22/11/2006 17:14 osgdb_acd.dll
22016 9555 57% 22/11/2006 17:38 osgdb_rgb.dll
69632 17306 76% 25/11/2006 11:52 osgdb_rgbd.dll
749568 280128 63% 22/11/2006 17:38 osgUtil.dll
3944448 983953 76% 22/11/2006 17:04 osgUtild.dll
30208 14929 51% 21/11/2006 14:49 pthreadVC2.dll
2054 891 57% 25/11/2006 13:59 README.bin
61 59 4% 24/11/2006 16:34 rfg.bat
36 36 0% 24/11/2006 16:28 rfghelp.bat
102 87 15% 25/11/2006 13:38 rfgufo.bat
------- ------- --- -------
54731148 13407524 76% 27
The batch file rfghelp.bat will show all the existing commands available to FlightGear; rfg.bat will run the default scenario, and rfgufo.bat will load the UFO aircraft ...
HAVE FUN ;=))
