Re: [Flightgear-devel] Re: Segmentation fault in FGTower
Quoth D Luff: Hmm, I'll have a think. If there's no resolution soon or if others start getting bitten by this I'll back this stuff out. This fault also as a nice side - I'm getting forced to learn about using CVS to update my local tree to a repository's former state ;-) You should presumably be able to just revert the ATC sub-directory to a few days ago. Since nothing in the main part of Flightgear depends on the ATC you'll still get the progress in the rest of FG without suffering this bug. I too am getting the bus error (I did not try a patch). Here's gdb output: [...] load() base = /Users/david/Desktop/FlightGear-CVS/fgfsbase/Scenery Loading tile /Users/david/Desktop/FlightGear-CVS/fgfsbase/Scenery/e000s10/e000s01/2954864 Program received signal EXC_BAD_ACCESS, Could not access memory. 0x0002fbc8 in FGTower::Update() (this=0x1202d070) at tower.cxx:171 171 ground-SetDisplay(); (gdb) bt #0 0x0002fbc8 in FGTower::Update() (this=0x1202d070) at tower.cxx:171 #1 0x00021f2c in FGATCMgr::update(double) (this=0xee06000, dt=0.443564001) at ATCmgr.cxx:153 #2 0x70c0 in fgMainLoop() () at main.cxx:1145 #3 0x3e001df4 in -[GLUTApplication run] () #4 0x3e01a48c in glutMainLoop () #5 0x60d8 in fgMainInit(int, char**) (argc=2, argv=0x39b920) at main.cxx:1725 #6 0x3c70 in main (argc=2, argv=0xbe10) at main.cxx:1817 #7 0x1f18 in _start (argc=2, argv=0xbe10, envp=0xbe1c) at /SourceCache/Csu/Csu-45/crt.c:267 #8 0x1d98 in start () (gdb) kill Kill the program being debugged? (y or n) y (gdb) quit Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Got FlightGear to compile on Mac OS X
Quoth Darrell Walisser: The culprit is likely PLIB. There is a fairly well-known and officially unresolved inefficiency in the rendering of small vertex arrays that is particularly painful on Mac OS X. You can view the original thread here (with the patch): http://www.menet.umn.edu/~curt/lists/fgfs/archive-200207/msg00404.html The current CVS version of ssgVtxTable (and specifically the drawGeometry method) differs pretty significantly from what is discussed in the message above. Has anyone tracked changes over time and could they submit a diff against a more recent version? Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Got FlightGear to compile on Mac OS X
Quoth Darrell Walisser: There is a fairly well-known and officially unresolved inefficiency in the rendering of small vertex arrays that is particularly painful on Mac OS X. Thank you for the reference. I was aware of this and thought I had checked against the right patches, but apparently not. I will report results later. Thanks again. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Got FlightGear to compile on Mac OS X
Hello everyone, I have finally (actually about a week ago but I've been out of town) gotten FlightGear to compile under Mac OS X 10.2.4. The results were surprising and I am probably going to rub a few feathers the wrong way in the process of explanation. I don't mean to offend but I need to be clear about what I see happening and sometimes plain language offends people. As you may recall, I was getting a linker error when linking fgfs. As someone more wise in the ways of ld than I pointed out, the method as compiled in tr.cxx was different from how the method call was being compiled in gui_funcs.cxx. The reason was that in tr.cxx, GLint was being defined as an integer, but in gui_funcs.cxx it was being defined as a long. Further exploration with the precompiler showed that SimGear was finding Apple's OpenGL gl.h, but FlightGear was finding XFree86's gl.h, and the two define GLint differently. Now I could just degenerate into name-calling about Apple's headers but as I looked around more in all the code that FlightGear uses I discovered that plib was not having any problems with the situation and that the linker wasn't complaining about the plib libraries. I found that plib's configure script was handling Mac OS X differently and specifically defining the location of glut.h to use Apple's OpenGL glut.h (which in turn includes gl.h). I am not a configure hacker but decided that I could emulate what plib was doing with some judicious complier defines in SimGear and FlightGear, just to see if it would work. I did and it did. It also took care of the error below that I had absolutely no idea how to address: ld: Undefined symbols: ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) Although, I still get this on my G4 tower where X, etc. are installed, even after I make the code changes in the attached patches. I was able to get FlightGear to compile from CVS by doing the following: - fresh install of Mac OS 10.2 (Jaguar) - install the 10.2.4 combined update - install the December 2002 Developer Tools - install the Apple update to GLUT, which just came out recently (just for kicks, probably isn't needed) - pull down CVS versions of plib, metakit, SimGear, and FlightGear - apply the attached patches - the patches to plib are per Jonathan Polley - the patches are against CVS from a few days ago - run the attached build scripts The compile does stop at one point, I haven't figured out why this is happening, but here is the event and the workaround (change gcc to g++): bash-2.05a$ cd SimGear/simgear/xgl/ bash-2.05a$ make clean test -z libsgxgl.a || rm -f libsgxgl.a rm -f *.o core *.core bash-2.05a$ make source='xgl.c' object='xgl.o' libtool=no \ depfile='.deps/xgl.Po' tmpdepfile='.deps/xgl.TPo' \ depmode=gcc /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/Users/david/Desktop/FlightGear-CVS/include -g -O1 -finline-limit=6 -finline-functions -faltivec -D_REENTRANT -c `test -f 'xgl.c' || echo './'`xgl.c xgl.c:10: header file 'GLUT/glut.h' not found cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode make: *** [xgl.o] Error 1 bash-2.05a$ source='xgl.c' object='xgl.o' libtool=no \ depfile='.deps/xgl.Po' tmpdepfile='.deps/xgl.TPo' \ depmode=gcc /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/Users/david/Desktop/FlightGear-CVS/include -g -O1 -finline-limit=6 -finline-functions -faltivec -D_REENTRANT -c `test -f 'xgl.c' || echo './'`xgl.c bash-2.05a$ make source='xglUtils.c' object='xglUtils.o' libtool=no \ depfile='.deps/xglUtils.Po' tmpdepfile='.deps/xglUtils.TPo' \ depmode=gcc /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/Users/david/Desktop/FlightGear-CVS/include -g -O1 -finline-limit=6 -finline-functions -faltivec -D_REENTRANT -c `test -f 'xglUtils.c' || echo './'`xglUtils.c rm -f libsgxgl.a ar cru libsgxgl.a xgl.o xglUtils.o ranlib libsgxgl.a No X, Apple or XFree86, no OpenGL, no freeglut, or glut, or fink. Which may bother people. Some Mac OS X users may not want to bother with these, understandably, in which case the SimGear and FlightGear code will have to be changed to compile this way. Others, more inclined to compile everything from source, will not want these changes in the code (even though they are already in plib) or will insist on a configure-time switch determining one behavior or the other. But the code (i.e. configure scripts and #include statements) is going to have to be changed/updated/complicated to accommodate the fact that Mac OS X may not have X, may have Apple's X, or may have XFree86; that it may have Apple's OpenGL and GLUT or not, or any combination of the above, so long as these header discrepancies exist. One issue that I am dealing with is that the frame rate is poor, even though precompiled versions I have had in the past had good (~30 fps) rates. It could
Re: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x)
Quoth Darrell Walisser: Is there a way to increase the size of the stack given to fgfs in Mac OS X? I heard of a ulimit command but my machine (10.2.4) doesn't seem to have this. Unsure if stack growing into the heap or vice versa is the problem here. I don't have this either (I used it once on a solaris box). Unless there is infinite recursion, you probably won't overflow the stack. I think you can adjust the underlying thread's stack size though (see man pthread). ulimit is a shell (bash and probably others) builtin, just run ulimit -a Read the bash man page for more information. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Undefined Symbols
[FlightGear-Devel readers: this is another installment in my quest to get FlightGear compiled under Mac OS X. I now have a good lead on the final link failure, I think. If you have any knowledge of linker naming conventions, symbol tables, and the like, I would appreciate your comments. Thanks. P.S. Everything is being built from CVS.] Previous make's were failing, unable to find gen_leaf or ssgVtxTable::ssgVtxTable. Sometime recently the call to gen_leaf was removed from the CVS code. Instead, three other symbols are now not being found. Here's the final make command along with output: david@Cynosure ~/FlightGear/src/main $ make g++ -DPKGLIBDIR=\/Users/david/lib/FlightGear\ -g -O2 -D_REENTRANT -L/Users/david/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lplibpsl -lmk4 -lz -lpthread -lm -framework GLUT -framework OpenGL -framework Carbon -lobjc -lplibsl -lplibsm -framework IOKit -framework CoreFoundation -lm ld: warning table of contents of library: ../../src/FDM/JSBSim/libJSBSim.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: Undefined symbols: trTileSize(_TRctx*, long, long, long) trImageSize(_TRctx*, long, long) trTileBuffer(_TRctx*, unsigned long, unsigned long, void*) ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) make: *** [fgfs] Error 1 I have been using nm to poke around and believe I know what is going on, even if I don't know how to fix it: david@Cynosure ~ $ nm -o lib/libsgscreen.a FlightGear/src/GUI/gui_funcs.o | egrep 'trTileSize|trImageSize|trTileBuffer' lib/libsgscreen.a:tr.o:1564 S _Z10trTileSizeP6_TRctxiii.eh lib/libsgscreen.a:tr.o:158c S _Z11trImageSizeP6_TRctxii.eh lib/libsgscreen.a:tr.o:01d4 T __Z10trTileSizeP6_TRctxiii FlightGear/src/GUI/gui_funcs.o: U __Z10trTileSizeP6_TRctxlll lib/libsgscreen.a:tr.o:03c8 T __Z11trImageSizeP6_TRctxii FlightGear/src/GUI/gui_funcs.o: U __Z11trImageSizeP6_TRctxll lib/libsgscreen.a:tr.o:036c T __Z12trTileBufferP6_TRctxjjPv FlightGear/src/GUI/gui_funcs.o: U __Z12trTileBufferP6_TRctxmmPv If you look closely at the T lines and the U lines, you will see that the symbol names do not match! No wonder the final link fails. I guess I need some way to get the compiler to generate the same symbol names. The other unfound symbol, ssgVtxTable::ssgVtxTable[in-charge] is trickier, but I found it. The sad thing is, the symbol names match, so I don't know why the symbol is not found. david@Cynosure ~ $ nm `find plib -type f -name \*.o -print` | egrep ssgVtxTable | egrep '^.[TU]' | sort +0.11 | uniq foo david@Cynosure ~ $ nm `find FlightGear -type f -name \*.o -print` | egrep ssgVtxTable | egrep '^.[TU]' | sort +0.11 | uniq bar david@Cynosure ~ $ cat bar U __ZN11ssgVtxTableC1EmP14ssgVertexArrayP14ssgNormalArrayP16ssgTexCoordArrayP14ssgColourArray david@Cynosure ~ $ egrep __ZN11ssgVtxTableC1EmP14ssgVertexArrayP14ssgNormalArrayP16ssgTexCoordArrayP14ssgColourArray foo U __ZN11ssgVtxTableC1EmP14ssgVertexArrayP14ssgNormalArrayP16ssgTexCoordArrayP14ssgColourArray 050c T __ZN11ssgVtxTableC1EmP14ssgVertexArrayP14ssgNormalArrayP16ssgTexCoordArrayP14ssgColourArray Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Undefined Symbols
Quoth David Drum: I have been using nm to poke around and believe I know what is going on, even if I don't know how to fix it: david@Cynosure ~ $ nm -o lib/libsgscreen.a FlightGear/src/GUI/gui_funcs.o | egrep 'trTileSize|trImageSize|trTileBuffer' lib/libsgscreen.a:tr.o:1564 S _Z10trTileSizeP6_TRctxiii.eh lib/libsgscreen.a:tr.o:158c S _Z11trImageSizeP6_TRctxii.eh lib/libsgscreen.a:tr.o:01d4 T __Z10trTileSizeP6_TRctxiii FlightGear/src/GUI/gui_funcs.o: U __Z10trTileSizeP6_TRctxlll lib/libsgscreen.a:tr.o:03c8 T __Z11trImageSizeP6_TRctxii FlightGear/src/GUI/gui_funcs.o: U __Z11trImageSizeP6_TRctxll lib/libsgscreen.a:tr.o:036c T __Z12trTileBufferP6_TRctxjjPv FlightGear/src/GUI/gui_funcs.o: U __Z12trTileBufferP6_TRctxmmPv If you look closely at the T lines and the U lines, you will see that the symbol names do not match! No wonder the final link fails. I guess I need some way to get the compiler to generate the same symbol names. I have just solved this problem using the brute-force method: # get rid of the current object file david@Cynosure ~/FlightGear/src/GUI $ rm gui_funcs.o # remake the object file david@Cynosure ~/FlightGear/src/GUI $ make source='gui_funcs.cxx' object='gui_funcs.o' libtool=no \ depfile='.deps/gui_funcs.Po' tmpdepfile='.deps/gui_funcs.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/Users/david/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o gui_funcs.o `test -f 'gui_funcs.cxx' || echo './'`gui_funcs.cxx rm -f libGUI.a ar cru libGUI.a new_gui.o dialog.o menubar.o gui.o gui_funcs.o gui_local.o mouse.o net_dlg.o preset_dlg.o prop_picker.o sgVec3Slider.o trackball.o ranlib libGUI.a # verify that the wrong symbol names are still being generated david@Cynosure ~/FlightGear/src/GUI $ egrep -l '__Z10trTileSizeP6_TRctxlll|__Z11trImageSizeP6_TRctxll|__Z12trTileBufferP6_TRctxmmPv' gui_funcs.o gui_funcs.o # change to correct symbol names david@Cynosure ~/FlightGear/src/GUI $ perl -p -i -e 's+__Z10trTileSizeP6_TRctxlll+__Z10trTileSizeP6_TRctxiii+g;s+__Z11trImageSizeP6_TRctxll+__Z11trImageSizeP6_TRctxii+g;s+__Z12trTileBufferP6_TRctxmmPv+__Z12trTileBufferP6_TRctxjjPv+g;' gui_funcs.o # remake david@Cynosure ~/FlightGear/src/GUI $ rm libGUI.a david@Cynosure ~/FlightGear/src/GUI $ make rm -f libGUI.a ar cru libGUI.a new_gui.o dialog.o menubar.o gui.o gui_funcs.o gui_local.o mouse.o net_dlg.o preset_dlg.o prop_picker.o sgVec3Slider.o trackball.o ranlib libGUI.a # see if the final link likes the new library david@Cynosure ~/FlightGear/src/GUI $ cd ../Main david@Cynosure ~/FlightGear/src/Main $ make g++ -DPKGLIBDIR=\/Users/david/lib/FlightGear\ -g -O2 -D_REENTRANT -L/Users/david/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lplibpsl -lmk4 -lz -lpthread -lm -framework GLUT -framework OpenGL -framework Carbon -lobjc -lplibsl -lplibsm -framework IOKit -framework CoreFoundation -lm ld: warning table of contents of library: ../../src/FDM/JSBSim/libJSBSim.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: Undefined symbols: ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) make: *** [fgfs] Error 1 Woo-hoo! An ugly method, but I'll take it. Now for the last error... Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Undefined Symbols
Quoth Bernie Bright: From simgear/screen/tr.h: extern void trTileSize(TRcontext *tr, GLint width, GLint height, GLint border); It looks like GLint is defined as an int when compiling SimGear but is long when compiling FlightGear. Thank you for the interpretation. The gui_funcs.cxx define of GLint is coming from /System/Library/Frameworks/OpenGL.framework/Headers/gl.h (the Mac OS X distribution of OpenGL). The tr.cxx define of GLint is coming from /usr/X11R6/include/GL/gl.h (the Mac OS X distribution of X11). I'll have to mull this one over a bit. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X: at a loss
Quoth Arnt Karlsen: sudo find / -type f -name libplibssg.a -print ..tried *plib* etc? Yes, at your behest. Same result. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X: at a loss
Quoth Arnt Karlsen: ..if this would have caught .*plib* (dotwhateverplibwhatever) too, it appears I just joined the at loss ranks. I believe so. Again, this is on a system which has had its disk erased and OS reinstalled between each attempt at compilation. I did not expect to find any rogue plib libraries. Trudging on... Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Mac OS X: at a loss
Hello everyone, If you've not worked with FlightGear under Mac OS X, delete now. OK, both of you that are left reading this, thanks. I'll make a long story short: every attempt I have made to compile FlightGear, whether 0.9.1 or from CVS, fails in the final link in the same way: ld is unable to resolve the symbols gen_leaf and ssgVtxTable::ssgVtxTable. I have attempted the compile in every permutation I can imagine, which is not a few. More importantly, I have attempted the compile on a fresh install of OS, etc. with as little as possible installed. Same error. I can only conclude that I am introducing the problem somewhere in the same way each time. I am installing: - Mac OS X 10.2.0 (minus all extra languages and applications) - Mac OS X Update Combo 10.2.3 (at this point I change my shell to bash) - Dec 2002 Dev Tools CD (plus BSD SDK) - StuffIt STD 7.01 OS X Install - Fink 0.5.0a (at this point I add the Fink init.sh to my .bashrc, and source it) - cvs-1.11.2.tar.gz (to support fink, installed via fink) - dlcompat-20021117.tar.gz (to support fink, installed via fink) - X4211src.tar.bz2 (via fink) (everything below is installed in a work directory in my $HOME) - plib-1.6.0.tar.gz - metakit-2.4.3-33.tar.gz - SimGear (via CVS) - FlightGear (via CVS) Here is the final link in the compile and resulting messages: g++ -DPKGLIBDIR=\/Users/david/FlightGear/FlightGear-20030103/lib/FlightGear\ -g -O1 -finline-limit=6 -finline-functions -faltivec -D_REENTRANT -L/sw/lib -L/usr/X11R6/lib -L/Users/david/FlightGear/FlightGear-20030103/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lpthread -lm -framework GLUT -framework OpenGL -framework Carbon -lobjc -lplibsl -lplibsm -lm ld: warning table of contents of library: ../../src/FDM/JSBSim/libJSBSim.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: Undefined symbols: ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) gen_leaf(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, unsigned long, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, bool, ssgVertexArray*) make[2]: *** [fgfs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Any thoughts would be greatly appreciated. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Off-Topic] Aircraft updates in CVS
Quoth Jon Stockill: On Thu, 9 Jan 2003, Andy Ross wrote: Indeed, Lee rocks. But seriously, someone needs to come to his home, tie him down and teach him Blender so that we can get some colors on these things. And make him do something non-british while you're at it. :) Non-British But we have some of the finest aircraft IN THE WORLD! :-) Quoted from www.auntymonkey.com, An Interview with the [Hot Air Balloon] World Chamion David Bareford:: 8. Why is England so good at ballooning but fairly average at every other sport? England has always been very good at aviation sports but because of that they never publicise it in the national press. We have a another tradition of inventing sports and beating the world until everyone else learns to play it then we end up getting thrashed - we then move on to inventing another sport. :-) Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Quoth Michael Bonar: Hi David. I get a Forbidden error when I try to reach that link. Terribly sorry. The link should have been http://www.more.net/~david/FlightGear-0.9.1/html/ I turned on about every option available, and also built the graphical class hierarchy. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Quoth David Megginson: Luke Scharf writes: Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Come to think of it, that sounds like a worthy project. There are snippits here and there (including under docs-mini in the source dir), but no big master document. I ran FG-0.9.1 through Doxygen the other day. It didn't croak, but it didn't produce much, either. I've put it up at http://www.more.net/~david/FlightGear-0.9.1/ for anyone who is interested. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X
Quoth Curtis L. Olson: If 0.9.1 is too much of a hassle to get running, please feel free to submit changes relative to current CVS, and we can do a 0.9.2 release and get a good Mac build for that. I removed the clouds3d code per a post of Curt's, and changed the tests in configure per a previous post of mine. The final link and resulting error message are below. I haven't had any luck changing the order of arguments to ld; if anyone can suggest an approach I would appreciate it. I have checked src/Objects/libObjects.a and it contains obj.o, which should contain gen_leaf. Likewise with ssgVtxTable in plib. g++ -DPKGLIBDIR=\/Users/david/FlightGear/FlightGear-0.9.1/lib/FlightGear\ -g -O2 -L/sw/lib -L/Users/david/FlightGear/FlightGear-0.9.1/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lpthread -lm -framework OpenGL -framework GLUT -lobjc -lplibsl -lplibsm -framework Carbon -lm ld: Undefined symbols: ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) gen_leaf(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, unsigned long, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, bool, ssgVertexArray*) Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ld: Undefined symbols error linking fgfs 0.9.1
Quoth Andy Ross: Some of the missing symbols (slScheduler et. al.) should be found in the Plib sl library, which for some reason doesn't appear on your linker command line. The reason is that $HOSTTYPE is not macintosh, it is powerpc. I checked 10.0.4 and 10.1 on a TiBook, and 10.2 on a G4 tower, and uname -p reports powerpc in all three instances. So I don't know where the original value macintosh came from. There are three instances of '$HOSTTYPE = macintosh' in configure that need to be changed to powerpc. See below. I am getting to the final link again, but getting a much different error. Progress! # less configure [...] # Check for audio support echo $as_me:$LINENO: checking for audio support 5 echo $ECHO_N checking for audio support... $ECHO_C 6 audio_LIBS= if test -r /usr/include/soundcard.h \ -o -r /usr/include/linux/soundcard.h \ -o -r /usr/include/machine/soundcard.h \ -o -r /usr/include/audio.h \ -o x$ac_cv_header_windows_h = xyes \ -o $HOSTTYPE = macintosh; then cat confdefs.h \_ACEOF #define ENABLE_AUDIO_SUPPORT 1 _ACEOF audio_LIBS=-lplibsl -lplibsm [...] # ./configure [...] checking for audio support... no [...] Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: ld: Undefined symbols error linking fgfs 0.9.1
I sent this to flightgear-users a couple days ago when 0.9.0 was out. No response. The same thing is happening now with 0.9.1, fresh compile of plib, metakit, and simgear (0.3.1). Still looking for help. Thanks. Quoth David Drum: I am compiling FG 0.9.1 on Mac OS X. The final link fails, it appears I am missing one or more libraries, but I cannot find any reference to them in plib, metakit, simgear, flightgear, opengl, or glut. Could someone help me out? Thanks. # # /Users/david/FlightGear/FlightGear-0.9.1 contains all the required sources, # i.e. plib, metakit, simgear and flightgear, and is the value I passed to # --prefix when running ./configure during all compiles # # /Users/david/FlightGear/FlightGear-0.9.1/FlightGear-0.9.1 is the actual # source tree # # cwd = /Users/david/FlightGear/FlightGear-0.9.1/FlightGear-0.9.1/src/Main # $ g++ -DPKGLIBDIR=\/Users/david/FlightGear/FlightGear-0.9.1/lib/FlightGear\ -g -O2 -L/sw/lib -L/Users/david/FlightGear/FlightGear-0.9.1/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgclouds3d -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lpthread -lm -lm ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _ceilf used from dynamic library /usr/lib/libpthread.dylib(ceilfloor.o) not from earlier dynamic library /usr/X11R6/lib/libGLU.1.dylib(mycode.o) symbol _floorf used from dynamic library /usr/lib/libpthread.dylib(ceilfloor.o) not from earlier dynamic library /usr/X11R6/lib/libGLU.1.dylib(mycode.o) ld: Undefined symbols: _CPSEnableForegroundOperation _CPSGetCurrentProcess _CPSSetFrontProcess _CPSSetProcessName slScheduler::loopSample(slSample*, int, slPreemptMode, int, void (*)(slSample*, slEvent, int)) slScheduler::playSample(slSample*, int, slPreemptMode, int, void (*)(slSample*, slEvent, int)) slScheduler::realUpdate(int) slScheduler::stopSample(slSample*, int) slScheduler::pauseSample(slSample*, int) slScheduler::resumeSample(slSample*, int) slScheduler::setMaxConcurrent(int) slScheduler::addSampleEnvelope(slSample*, int, int, slEnvelope*, slEnvelopeType) slScheduler::init() slScheduler::~slScheduler [in-charge]() slDSP::open(char const*, int, int, int) slDSP::close() smMixer::smMixer[in-charge]() smMixer::~smMixer [in-charge]() slSample::loadFile(char const*) slSample::autoMatch(slDSP const*) ___slPendingError ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) gen_leaf(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, unsigned long, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorPoint3D, std::allocatorPoint3D const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint const, bool, ssgVertexArray*) _CGLGetCurrentContext Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] config.guess and config.sub
Hello developers, I am building plib on Mac OS X for use with FlightGear. The version of autoconf included with plib-1.6.0 is very old. Regardless of your plans to update it, I would like you to know that I was able to get plib to configure and make successfully (not yet tested) on Mac OS X by copying config.guess and config.sub from autoconf-2.57. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] config.guess and config.sub
Quoth Steve Baker:
I'm suprised you needed to do that though - so long as the versions
of those two files agree with the version of autocong that *I* used
to build the 'configure' script, it shouldn't matter what versions of
the auto* tools you have because you don't use them when you just run
the configure script.
You can always get the right versions of config.guess and config.sub
by removing any old versions and running:
automake --add-missing
I do this when building the auto* stuff from scratch (eg after a CVS
download):
rm -f config.*
aclocal
automake --add-missing
autoconf
./configure
Thank you for your quick reply. I have to admit I am not an autoconf
expert. I will try out what you suggest. Below is what I saw, in case
you are interested. After that is your method (note warnings about
missing script).
$ tar xzf plib-1.6.0.tar.gz
$ cd plib-1.6.0
$ ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E -traditional-cpp
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking how to run the C++ preprocessor... c++ -E
checking for a BSD compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking host system type... configure: error: can not guess host type; you must
specify one
$ cp ~/tmp/autoconf-2.57/config/config.guess .
$ ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E -traditional-cpp
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking how to run the C++ preprocessor... c++ -E
checking for a BSD compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking host system type... Invalid configuration `powerpc-apple-darwin6.2': system
`darwin6.2' not recognized
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for glNewList in -lGL... yes
checking for gluLookAt in -lGLU... yes
checking for glutGetModifiers in -lfreeglut... no
checking for glutGetModifiers in -lglut... no
configure: error: could not find working GLUT library
$ cp ~/tmp/autoconf-2.57/config/config.sub .
$ ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E -traditional-cpp
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++
