FG OSG MSVC9 - second build

external: index
internal: update | preamble | folders | building | details | downloads | images | notes | next | end


2008-11-28: Update, including 'boost' dependency, see next page fgfs-047.htm, but much of this page is still relevant, and should be read, or at least scanned first!.

2008-11-11: Sort of an update. All of the following page is about building with MSVC9 (Microsoft Visual Studio C++ 2008 Express Edition), but I wanted to try build with earlier versions of MSVC, namely versions 6, 7.1, and 8, so have a new page, fgfs-046.htm (in development), for that ...

But in doing this I also incorporated some of the changes into my 'build set', so a new download set has been added. This also includes the new vc6dsw02.zip, which contains the DSW/DSP files to build flightgear with any version subsequent to MSVC6 ... sadly MSVC6 (circa 1998) itself fails - just too OLD ... Using this new DSW/DSP zip, I got a clean build, and was up and flying within about 2 hours!

2008-10-05: Update done, with a few minor folder changes, and to my batch files. The main folder change was to use the later 'lpng1232' source, from a downloaded ZIP file, and stopped chasing this version number in the work folders, and called the folder just 'lpng'. And I fixed one or two minor aberrations in my UPD.BAT batch file, and some others were 'improved' ... see new folders of this date, and newer downloads ...

For the first time I got some 'strange' errors during the OpenSceneGraph build using MSVC9, after creating the solution files with CMake 2.4 ... it seems to generate a target that does not exist, and ended with an error. It all cleared up when I ran CMake a 2nd time, generated the solution files gain, and reloaded MSVC9 and built (F7) ... then I got some 66 builds succeeded ;=)) I only built the Release version ... and was not present in later CMake 2.6 runs ...

As I suggest, my first FlightGear full build (Release) was without applying the vc9chg04.zip file, but found I still needed some fixes, so eventually unzipped it as well ... it is important you try to do without these 'fixes', just to see if the latest source already has a fix. The 'main' change is the location of 'al.h' ... it is expected to be in an AL folder, <AL/al.h>, but now that I am using the OpenAL SDK, that AL folder no longer exists ...

Even with all the small changes, I was flying within half-a-day, but of course that does NOT included all the source downloads, and updates ... Have FUN ;=))



2008-09-15: My last build was back in April, so this was overdue ;=(( Naturally I used my own   TWO SOLUTION SYSTEM (TSS)  ;=)) This original effort was spread over about  5 days, as other things interrupted, but the total time was about 1 full working day, excluding the original 'checkout' of the sources, but did include 'updating' the sources.

On building FlightGear, as Stefan recently put it - It's very simple: download, build, analyze errors, build missing 3rd party lib, repeat - and, for sure, this I agree is the basic strategy ... Here I have tried to build a fully automated system with batch files, and MSVC9 solution files, but it goes OUT-OF-DATE so quickly in an active environments like OSG and FG/SG ...


Folders - directory structure:

My batch files, and TSS depend entirely upon you creating the SAME directory structure as I have. Changing one means patching the main SETUPFG.BAT batch file, extracted form vc9sln02.zip, and usually lots of other things as well. And changes have a sort of ripple effect, and can be difficult to fully resolve downstream in the build ...

I have the disk space, and always COPY from what I call the SOURCE directory, and create a new WORK directory. If you include the FG data, after the build this work folder can occupy in excess of some 4.2GB, some 46,000 plus files, so make sure you have the space ... of course the FG data alone represents about 1.5GB, some 34,000 files, and that is ONLY the default 'base' download, but you do NOT have to really copy this, but then you must at least patch my flightgear run batch files, in bin/bats before flying ...

2008-10-05 2008-09-15
Image of SOURCE directory Image of WORK directory Image of SOURCE directory Image of WORK directory

In simple terms, my SETUPFG.BAT batch file expects the directories as shown in the SOURCE column, in my case in a directory C:\FGCVS, and will CREATE the directories shown in the WORK, and copy the appropriate sources to the work, using the XCOPY command ... in my case I used a ROOT of work of C:\FG, and chose my new work to be 22, thus ran SETUPFG as -

C:\FG> setupfg 22

After SETUPFG has successfully run, change into the WORK and fully unzip vc9sln02.zip, with directories, overwriting any existing files, and you are ready for the build.

My prerequisites page may help you locate some of these sources, but some links may fall out-of-date - just use a Yahoo! search ...


Build Process:

The build process remains exactly as per my previous April, 2008 build, except for the treatment of OpenAL and alut, and can be summarized as :-

A: Download and install OpenAL SDK. Run oalinst.exe to INSTALL OpenAL32.DLL, and wrap_oal.dll, into $(SYSTEMROOT)\System32 folder. This, like the alut.dll copy mentioned in 14. below, requires administrator privileges.

B: In brief, the build steps are :-

  1. Download vc9sln04.zip, and extract SETUPFG.BAT, to a ROOT where the WORK folder is to be created.
  2. Adjust SETUPFG.BAT to the ROOT of the SOURCE folder. i.e. where you put the up-to-date sources...
  3. Using SETUPFG.BAT, giving the WORK folder to be created, copy sources to a NEW work folder.
  4. Unzip the full vc9sln04.zip into the new WORK folder.
  5. Unzip vc9cfg04.zip, preserving paths ...
  6. Unzip vc9chg04.zip, if any, preserving paths.
  7. Load MSVC9, and open fgfs/fgfs.sln OR unzip vc6dsw02.zip and load fgfs/fgfs.dsw!...
  8. Build just the libpng and zlib projects.
  9. Run CMake on the OpenSceneGraph folder, selecting MSVC9 (see Note 1 below).
  10. Load MSVC9, and open OpenSceneGraph.sln, and build Release.
  11. Reload MSVC9 with fgfs.sln, and build Release (and optionally Debug).
  12. Unzip rfgbatsnn.zip with folders ... these will be put in bin/bats
  13. In the MSVC command prompt, since it uses nmake, run UPD.BAT. (see Note 5 below).
  14. Copy release alut.dll to $(SYSTEMROOT)\System32 folder. and run UPD.BAT (see Note 2 below).
  15. cd bin\bats, and try rfgufo, or any of the other batch file available ...



Build Details


This was actually using MSVC8, in a modestly fast machine - XP SP3, in Dell Dimension DXP061, CPU: Intel Core 2 6400 @ 2.13GHz; 1GB RAM, 256MB ATI Radeon X1300PRO, but in general, it applies to _ALL_ version of MSVC later than version 6.


Update all the SOURCE, using CVS or SVN, as appropriate ... a few sources are via a 'tarball' or zip only.



Download vc9sln04.zip and extract SETUPFG.BAT into root of WORK folder. In my case C:\FG



Adjust SETUPFG.BAT to the ROOT of the SOURCE folder. The default is C:\FGCVS and requires no adjustment if this is used.



Run SETUPFG.BAT, giving the WORK folder to be created, copy sources to a NEW work folder. (including 'data'). In my case >setupfg 26



Unzip the full vc9sln04.zip into the new WORK folder, using folder name, and overwriting existing files. In my case C:\FG\26



Unzip vc9cfg04.zip, preserving paths ...



Unzip vc9chg04.zip, if any, preserving paths. As advised, this should be periodically checked to ensure _ALL_ changes are still required.



Unzip vc6dsw02.zip and load fgfs/fgfs.dsw (or fgfs/fgfs.sln) in MSVC and allow conversion. I use fgfs/fgfs.dsw and allow conversion and [No] to load existing VC compatible project files. The DELSLNLIST.BAT can be used to 'rename' all the current VCPROJ files, then this 2nd dialog is avoided.



Build just the libpng and zlib projects. I use Build -> Batch ... selecting both libpng, zlib, and alut, then [Build]



Run CMake (2.6) on the OpenSceneGraph folder, selecting MSVC. Check [x] Show Advanced; set ZLIB include to C:\FG\26\zlib-1.2.3, and ZLIB library to C:\FG\26\zlib-1.2.3\zlib.lib; [Configure] again; set PNG include to C:\FG\26\lpng, and PNG library to C:\FG\26\lpng\libpng.lib; [Configure] again, the [OK] to build solution set.



Load MSVC, and open C:\FG\26\OpenSceneGraph.sln, and build Release. Some 72 projects ...



Reload MSVC fgfs.sln, and build the Release



Unzip rfgbatsnn.zip, with folders ... these will be put in C:\FG\26\bin\bats



In the MSVC command prompt, since it uses nmake, run UPD.BAT.



Copy release alut.dll to $(SYSTEMROOT)\System32 folder, to join where the OpenAL32.dll, and wrap_oal.dll reside, if not done previously.



cd bin\bats, and try the rfgufo, rfg, or any of the other batch files available






This above table was only the 'Release' configuration. Building the Debug configuration took another hour or so ... then, if I wanted I could do, in a MSVC command prompt :-
C:\FG\26\upd d
to copy all the DEBUG DLLs to the bin folder, ready to RUN the Debug version ...



This first process first took me a good working day to complete - it had been a good 5 months so there were many changes. Here are the times, and notes made. The effort was actually spread over about 5 days, as other things interrupted, but as can be seen it took about 8 hours, to build, research errors, fix errors, and continue building - repeat ...

If you do NOT want to read all this detail, then skip it ...

As can be seen above, after getting all the sources fixed, and the new DSW/DSP files, it actually took about 1.5 hours to do the Release build in another machine. And about 1 hour more for the Debug build.

Time line of a FG build in Vista, using MSVC9 - spread out over 5 days - 20080910 - 20080915
  Update SVN/CVS sources. Had not done it in a while, so it took some time … also OpenAL had changed its location - see Note 3 below. 12:24 12:53 00:29
  Researching OpenAL, and choosing what to do … 12:40 14:36 01:56
1 Download vc9sln01.zip, and extract setupfg.bat, to a BASE WORK folder, and in this case adjust it to remove OpenAL 12:50 13:11 00:21
2 Update all sources again since it has been a few days … and sure enough there were a few more changes … 15:31 15:40 00:09
3 Copy sources, including FG data, to new folder 22, using setupfg.bat … noted a problem with lpng1225, which should probably be undated anyway … 15:40 15:57 00:17
  From my prerequisites page - http://geoffair.net/fg/prereq.htm - note lpng is now 1.2.31, so update to this … and see there is also a 1.2.32rc01 … 15:57 16:05 00:08
  Get lpng1231.zip, and put in <sources>\lpn1231 folder, and adjust setupfg.bat for next time. And copy source to 22/lpng1231 … 16:05 16:12 00:07
4 Unzip all vc9sln01.zip to my new folder 22 … but manually copy libpng.vcproj to its new location visualc71, and adjust the fgfs.sln to match … and at the same time remove all OpenAL ... 16:12 16:31 00:19
5 Unzip vc9cfg01.zip, ignoring the OpenAL item 16:33 16:36 00:03
6 There is a vc9chg01.zip, but it only contains OpenAL items, so skip this … 16:31 16:33 00:02
7 Load MSVC9, and open fgfs/fgfs.sln ... 16:33 16:37 00:04
8 Build just the libpng, and zlib projects - Release, and Debug - quick, and no problems ;=)) 16:37 16:39 00:02
9 Run CMake on the OpenSceneGraph folder, selecting MSVC9. Initially I could not find the PNG_... Options even with [x] Show Advance Values checked. 16:40 16:48 00:08
  But after running [ Configure ] the first time, the PNG items appeared ;=)) After setting the pointers to lpng1231, another [ Configure ] and had no 'red' items, so proceeded to [ Ok ] … 16:48 16:52 00:04
10 Load 2nd MSVC9, and open OpenSceneGraph.sln, and build Debug first ... 16:53 17:31 00:38
  Then OpenSceneGraph Release … I later CLEANED the whole 69 project solution and ONLY built 'Release' - about 30 mins 17:31 18:03 00:32
11 Reload MSVC9 with fgfs.sln, and remember to adjust SG/FG includes to C:\Program Files\OpenAL 1.1 SDK\include … but this points out I may still require ALUT? But where is it? Ha, maybe it is 'freealut' ? But start Debug compile 18:04 18:12 00:08
  But ends with lots of ERRORS, some 'strange' - C2471: cannot update program database, and C1083 cannot open program database … switch to Release … 18:18 18:38 00:20
  One of course is cannot locate <AL/al.h> … well that is understandable, since the OpenAL SDK no longer puts al.h in an AL folder … create a new switch USE_OPENAL_SDK, and use just <al.h> under this switch …      
  BUT THIS DOES NOT GET OVER THE MISSING alut.h??? But make some easy corrections and compile again … 18:38 18:40 00:02
  But without an alut.h, ALUT_API_MAJOR_VERSION is not defined, and the code falls back to what is comments as 'pre 1.0 alut version' …
I download ALUT, freealut-1.1.0-src.zip from the creativelabs site … and add it to the sources in freealut-1.1.0-src folder … In my new 22 create a copy in alut folder … it has an include/AL/alut.h …
  And it has both .sln and .dsw files … I add the alut.vcproj to the fgfs solution …
This points out that (a) it needs access to alc.h, in OpenAL 1.1 SDK/include, but it already points to 'OpenAL 1.1 with EFX SDK'! Did I download, and install the 'wrong' SDK?
But reading the creativelabs openal it seems the OpenAL11CoreSDK I downloaded includes 'X-RAM Extension, the Effect Extension (EFX), etc, so maybe I should just correct it to my 'OpenAL 1.1 SDK/include' folder …
After a few other minor fixes, am rewarded with an alut.dll, which I copy to C:\Windows\System32 - that is INSTALL it - of course this must be done as 'administrator' in Vista … and there is an alut.lib ready for links …
And to get to alut.h, must add an include path to SG/FG to ..\alut\include … and later a path to the alut.lib … and this is why I prefer to copy to a work 'alut', than use the 'freealut-1.1-src' folder in the zip … 19:20 00:39
Back to compiling … 19:20 19:30 00:10
Time to remove the 'missing' files from the solution … of course there may be other to add later to replace these files …
transmissionlist.cxx, transmission.cxx, trafficcontrol.cxx, tower.cxx, tileentry.cxx, sgVec3Slider.cxx, newcache.cxx, mouse.cxx, MagicCarpet.cxx, gui_local.cxx, ground.cxx (which is good because there is a Ground.cpp also), commlist.cxx, BalloonSim.cpp, Balloon.cxx, atis.cxx, ATCVoice.cxx, ATCUtils.cxx, ATCProjection.cxx, ATCmgr.cxx, ATCDialog.cxx, ATC.cxx, approach.cxx, AIPlane.cxx, AIMgr.cxx, AIlLocalTraffic.cxx, AIGAVERTraffic.cxx, AIEntity.cxx, trackball.c - WOW, it seems I should have run my fgam2dsp.pl first ;=)
19:30 19:52 00:22
AND I GOT MY FIRST LINK - Ok, there are some 90 missing externals, but it is just time to track these down, and add the files …
First one FGNavRecord::get_cart … found in FG/src/navaids/navrecord.cxx
FGTowerController::announcePosition, in FG/src/ATC/trafficcontrol.cxx
Ha, it seems a whole bunch deleted have just moved house to ATCDCL, so add al the *.c* files in here …
Things like _modelloader, TileCache, etc, turn out to be missing from SG … so are added to SG library …
Working on these missing external, virutally one-by-one, is a steady process. I use my own grep like tool to locate it in the appropriate source ...
19:52 20:30 00:38
When everything is in place, and all corrections done, an actual simple build of the Release of fgfs.sln (15 projects) takes only about 15 minutes, and that is IGNORING the some 234 warnings issued! Below, Note 4, is an analysis of the warnings issued.
12 In the MSVC Command prompt, run upd.bat, since it uses nmake - As usual with this step, it FAILED the first time … OSG sets new 'version' numbers from time to time, and the upd.bat needs to be corrected to use these numbers … 16:20 16:34 00:14
There should be a way to 'automate' these OSG version changes … maybe through a Perl script …
13 Unzip rfgbats09.zip with folders ... these will be put in bin/bats - this presently includes a OpenAL install batch … 16:34 16:36 00:02
14 As mentioned above have now switch to using the OpenAL 1.1. SDK … and did a manual copy of alut.dll into C:\Windows\System32 to join its OpenAl32.dll and wrap_oal.dll mates ;=))
15 cd bin\bats, and try rfgufo, or any of the other batch file available …


Toured over the Golden Gate, and found an Aircraft carrier tooting along, another ship head for the port, and other craft … and back in SF bay, I note other boat activity, all added since April ... next I expect to see 'traffic' going of the GG bridge ;=))
Frame rate was consistently in the high 80's, with a top of over 134 frame per second …


The console showed a few 'warning', seemingly from nasal - something about 'unauthorized access', but only a few, and it flew, and flew and flew … see console warnings ...
TOTAL 07:38

Of course, if you KEEP the sources up-to-date, and continually apply fixes to the solution files, a full re-build should only be a few hours ;=)) This detailed account has also been repeated on the fgfs-045b.htm page ...



This first, vc9sln04.zip contains my TSS solution files, and other thing, and fgvc9rt04.zip contains the binary executable FlightGear.exe, and all the DLL needed to run it, including OpenAL32.DLL, wrap_oal.dll, and alut.dll, in OpenAL-04.zip. 03 and 02 are earlier versions ...
Take care downloading and running executables from the web ...

Date Zip Size MD5
Version 2008-11-11
11/11/2008 vc9sln04.zip 204,977 1f39ef59239429f0f4565b0cdac2dcb4
11/11/2008 fgvc9rt04.zip 5,623,491 8e1b4987ea59e3fb87ea62019f352eeb
Earlier Versions
05/10/2008 vc9sln03.zip 133,205 ebb95f780bf8541fc71b6ef2e4be92cc
05/10/2008 fgvc9rt03.zip 5,315,369 42fe24624657ab4e612d22e6854af975
17/09/2008 vc9sln02.zip 131,343 897de5480d5edb1c8be7fe1a69c5338a
17/09/2008 fgvc9rt02.zip 5,225,994 541ef5870036f938ca70f6c5eeed2557

PS: This page was updated 12 November, 2008, 5 October, 2008, and 17 September, with corrected solution files, and new binaries. Ensure you use these latest updated zip files, especially if you by chance downloaded the 15 Sep files, which failed to build the Debug configuration. I have learned I should NOT try to manually fiddle with MSVC9 solution files ;=))



This is NOT recommended, but quite a few have asked for it. This is a COMPLETE zip of ALL the sources used to build the above. Remember this is only the SOURCE folders, EXCLUDING FlightGear\data. The base data must be downloaded from the FG site. And then vc9sln04.zip must still be downloaded, and the extracted SETUPFG.BAT used to create the WORK folder, and then the vc9chg04.zip and vc9cfg04.zip applied to it, etc, etc, as above ... before the build ...

It is LARGE - 15MB - It is STALE - fixed as of this date. You should download and use the LATEST sources, which is EASY, per my prerequisites page ... this is ONLY for LAZY, STALE people ;=))

Date Zip Size MD5
11/11/2008 full source 02 zip 16,702,979 99ad559d874f4938de969deeec5728c2
05/10/2008 full source 01 zip 16,635,824 e5b984aedec41d45517d28f3dc72f10c

In fact, I am sure using this will still be a problem for some. Remember, it is STALE sources, and can NOT be later updated with CVS/SVN, etc. I will always HELP if you do the proper source downloads, but certainly do not bother to write to me about any problems using this STALE source!


Some Images

Downtown SF with the bridge in the background using UFO. The carrier, with other vessels, outside SF, using UFO.
downtown with bridge in background ships near SF

I had a strange problem with the panel of the default Cessna and Concorde, but F18 looked ok ...
cessna panel concorde panel f18 panel
Do not know what is the difference, nor the problem ...
In the Cessna, this is the 3D panel, and toggling the 2D panel is also blank!
But after a data folder update, source folder update, and complete rebuild, it came out right ;=))
cessna panel nearly ok - missing radio stack
This is better, but the radio stack and the Concorde stayed all blank???

But later, in another machine, the radio stack appeared ;=)), with a nice setting sun, and relatively new yellow signs
taxiing in c172
These signs appear to be in on the taxiway!
new taxiway signs
Close up to one of the parked aircraft
parked aircraft at KSFO

And this is an odd view, from about 100,000 feet up in the UFO looking straight down, all clouds cleared, in the 'base' scenery package, exactly over KSFO - it shows the 'square' extent of the tiles loaded ... the light blue 'border' is where there is NO scenery tile have been rendered, even though they may have been loaded :-

vertical view from 100,000 feet up

This could be considered a sort of a 'feature' of the tile loader, since all scenery outside this square has not been displayed, probably due to the 'distance' - and actually this block 'disappears' completely if you rise above about 104,000 feet.

Of course, for some parts of the area there is no scenery since this is just the scenery blocks of the 'base' package of :-

C:\FG\26\data\Scenery\Terrain\w130n30\w122n37 and w123n37

You have to go to -
This is the graphical interface for version 1.0.0, but may be there will be 1.0.1 or better by the time you do the download ... it is in 10x10 degree chunks. These 'chunks' ranges from about 1K up to 170MB, depending on the content, so make sure you have the space and time for the downloads ...


Console Output

Maybe it has something to do with the 'nasal' error shown in the console window -

  Model Author:  Unknown
  Creation Date: 2002-01-01
  Version:       $Id: c172p.xml,v 1.20 2008/09/01 15:14:33 torsten Exp $
  Description:   Cessna C-172
WARNING: JS: Failed to read joystick name from registry
FGMultiplayMgr - No receiver port, Multiplayermode disabled
loadxml: reading '../data/gui/dialogs/NTPS_target_task.xml' denied
 (unauthorized access)
Nasal runtime error: Dialog class: XML dialog must have <name>
  at ../data/Nasal/gui.nas, line 232
  called from: ../data/Nasal/gui.nas, line 217
  called from: ../data/Nasal/globals.nas, line 76
Nasal runtime error: container index not scalar
  at ../data/Nasal/gui.nas, line 219
  called from: ../data/Nasal/lead_target.nas, line 412
Initializing Nasal Electrical System
power up

The JS warning is understandable, since as far as I know, the name of the joystick is not written to the registry in Vista ... I have subsequently found some WIN32 code which will yield the 'name' of the joystick, and may try to get PLIB to accept it, if I get a chance ... see Joyinfo
But why the loadxml: say 'denied (unauthorized access)' is a mystery ... the file is there, and has normal attribute ... something goes wrong with the very convoluted way the file is checked - setting up a string in the properties, and using a tied function ??? ... I subsequently tried running in the Vista 'Administrator' mode command prompt, but  these 'nasal' errors still appeared on the default c172 - they do not appear for the UFO ... back to time table ...



Note 1: OSG Plug-ins for ZLIB and PNG
Make sure you CHECK [x] Show Advanced Values, and correctly point -
(i) ZLIB_INCLUDE_DIR to the zlib-1.2.3 folder, and ZLIB_LIBRARY to zlib-1.2.3/zlib.lib, and
(ii) PNG_PNG_INCLUDE_DIR to the lpng1231 folders, and PNG_LIBRARY to lpng1231/libpng.lib
or else some VERY IMPORTANT add-ons will NOT be built. back to CMake ...


Note 2: Installing ALUT.DLL
I tried using upd.bat to complete this step - that is to copy alut.dll to C:\Windows\system32, but it failed, since I was not running as 'administrator' - so this step has been left as manual, but is ESSENTIAL ...
If you want to try the openal DLLs I used, then -
date:14/09/2008 link:OpenAL32.zip size:258,000  MD5:514b5521e330bb41230c5480ab3c6d6b
contains OpenAL32.dll, wrap_oal.dll, and alut.dll from my system32 folder - but it is highly recommended you use those from the Creative site, and build alut.dll yourself. You still need the headers and library files anyway! - back to alut


Note 3: More on OpenAL and ALUT
From : http://connect.creativelabs.com/openal/default.aspx - and searching around, advises use:
svn://connect.creativelabs.com/OpenAL … but what to do with that???
It seemed difficult to find the SVN source - They do offer a Windows Installer, and an OpenAL SDK … maybe I should switch to these!
The oalinst.zip downloaded contains oalinst.exe, which contains OpenAL32.dll and wrap_oal.dll, the binary runtimes, but to develop also need the 'libraries' and API headers, which I assume will be in the OpenAL11CoreSDK.[zip/exe] … BAH! Choices!!!
Since in Vista there is more 'protection' of the 'Windows' folder, so even if I do compile them myself, they still have to be 'installed' somewhere … I decide to go with this SDK solution, and forgo building it myself for now …
As suspected running oalinst.exe just copied OpenAL32.dll and wrap_oal.dll to my C:\Windows\System32 … more or less what my batch files system was doing …
Then running the OpenAL11CoreSDK.exe, I had some initial problems 'seeing' the InstallShield Wizard window, until I threatened to reboot !!! It offered to install it in the usual C:\Program Files\OpenAL 1.1 SDK, which I accepted …
Wow it was SLOW - I thought it had stalled … it eventually came back with a question - Do I want the help files integrated with Visual Studio NET?
More choices … I accept the default, hoping …
The next question was do I want to launch the redist installer … I choose NO for this …
It reported OpenAL 1.1 Core PC SDK [ver 3.03] installed … and finished …
Now in the 'OpenAL 1.1 SDK' folder I find libs\Win32\OpenAL32.lib, so that part is there … and in 'include' some headers … so maybe this is OK ???
But what about ALUT ??? Will find out later I suppose … and I did - I download ALUT, freealut-1.1.0-src.zip from the creativelabs site, and added this source build to my fgfs solution ...

It is ALSO possible to download the OpenAL source software, but for this you need to install GIT -
 http://code.google.com/p/msysgit/downloads/list … I chose Git- …
It installed in C:\Program Files\Git … I chose to NOT alter my PATH, but was able to run git.exe in 'bin' through a batch file …
From http://kcat.strangesoft.net/openal.htm the GIT respository was through -
prompt> git clone git://repo.or.cz/openal-soft.git openal-soft
and I think I got the source … maybe ??? I also downloaded the openal-soft-1.5.304.tar.bz2 … But for now will go with the SDK … and later learned, after changing into the open-soft directory -
prompt/open-soft> git pull origin
would do a source update. It has the problem in that it emits ANSI color escape sequences, but my standard console does NOT support these sequences, so the output includes these escape sequences ...  back to Update ...


Note 4: Warnings seen during build
Analyzing the warnings yields (approx) -

Count Warning Type
81 C4244 like '=' conversion 'time_t' to 'DWORD' possible loss of data
47 C4800 'unsigned int; : forcing bool (which is a char in WIN32)
44 C4101 unreferenced local variable
27 C4018 sign/unsigned mismatch
26 C4013 like 'uiuc_init_aeromodel' undefined; assume extern …
23 C4996 name is depreciated … use ISO conformant …
11 C4305 truncated from 'double' to 'float'
3 C4355 'this' used in base initialize list
2 C4715 not all control paths return value
1 C4554 '&' : check operator precedence; use parentheses to clarify
1 C4390 empty controlled statement; is this the intent?
Return to details ...


Note 5: UPD.BAT - Important Information:
The UPD.BAT attempts to check if everything has been built, and may exit with errors it finds. Obviously if it is not an error, then manually adjust UPD.BAT. It does a LOT of things, so is QUITE complicated.
One of the 'normal' errors are the OSG version numbers. OSG regularly updates three different 'version' numbers, and if UPD.BAT finds an error, it attempts to SHOW the new OSG version numbers.
It does a directory listing of the files it expected to find, and shows you their current version numbers.
If you have Perl installed, then it will run a perl script to also try to find the new numbers.
With this information you should be able to manually patch UPD.BAT near the top, with the new version numbers.
Further, by default it only 'installs' the Release version to the 'bin' folder. With an optional 'D' parameter, it will also install the Debug configuration. This debug section is less tested, so it it better you install the Release alone first, and if this is successful, then try the 'D' also if needed ...
Essentially ALL it is doing is copying MOST of the OSG DLL, both base and plug-in, as well as the FlightGear.exe, to the 'bin' folder for running ... back to build ...


I purchased and use WinZip, and its command line interface for most 'zip' type files, but this version 9 I have does not handle certain files. For example, for a command line tool to unpack *.bz2 files, among others, I downloaded the 7-Zip command line tool. I downloaded the 7za460.zip, using Vista native zip extraction to get 7za.exe, which I place in a directory in the PATH environment variable ... I have a special simple place for all these command line tools call C:\MDOS, which I added to my PATH ...



As my update of 11/11/2008 states, I have now generalized this build process by reverting to using MSVC6 DSW/DSP files, so it can support _ALL_ versions of MSVC later than MSVC6 - OSG, SG, and possibly FG, can no longer be fully compiled with MSVC6 - but these DSW/DSP files can be 'converted' by MSVC7.1 (2003), MSVC8 (2005), MSVC9 (2008), and hopefully even later versions, to their own formats ... vc6dsw02.zip is now included in the above vc9sln04.zip ...

I still have to work harder on my fgam2dsp.pl, and sln2dsw.pl perl scripts, and they take real time to fully debug given what they are trying to do is sort of undocumented ... this will allow me to keep the DSW/DSP set more up-to-date ... but we will have to see how the time pans out ...

EOP - fgfs-045.htm


checked by tidy  Valid HTML 4.01 Transitional