Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Dennis B. D'Annunzio wrote: I thought I successfully compiled and installed SimGear-0.3.1. However, whem making FlightGear-0.9.1 under cygwin (xwindows was removed), I get this message: nt/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 -lop engl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinm m -lm Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Erik Hofman writes: Dennis B. D'Annunzio wrote: I thought I successfully compiled and installed SimGear-0.3.1. However, whem making FlightGear-0.9.1 under cygwin (xwindows was removed), I get this message: nt/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 -lop engl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinm m -lm Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Hmm... -lopengl is there in the link line -lopengl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lm *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. so in this case '-lopengl32' must come after '-lglut32' and '-lglu32' This was working correctly. has configure.ac changed this recently FWIW I won't have time to investigate this much deeper for a couple of days Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Norman Vine wrote: Erik Hofman writes: Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Hmm... -lopengl is there in the link line -lopengl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lm *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. so in this case '-lopengl32' must come after '-lglut32' and '-lglu32' This seems akay in the current source: LIBS=$LIBS -lglut32 -lglu32 -lopengl32 Maybe you should check there isn't any configure.in in the FlightGear source and run autogen.sh again. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Norman Vine wrote: -lopengl is there in the link line *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Actually, Unix-style compilers are sensitive to link order issues too. The only thing that makes it seems simpler under Linux is that shared libraries (unlike DLL's) can export their dependency information to the linker and automatically pull in the needed libraries in the proper order. For example, many OpenGL test programs link correctly if you simply specify -lglut on the command line. All the other libraries (GLU/GL/Xext/X11/m, off the top of my head) will get pulled in automagically. Something tells me that recent versions of GCC had some new features in this area, but I can't remember what they were. Maybe the link order isn't a problem any more? I was playing with this last week while writing an automatic dependency build tool for C/C++ projects. plug mode=shameless It's actually working pretty well, if anyone wants to see it. You just drop code into a local ./src directory and it all gets compiled magically into program files that have a prog- prefix. Saves a lot of annoying Makefile/autoconf drudgery; I got a little spoiled these past four years doing Java stuff at NextBus./plug Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Andy Ross wrote: *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Yes, it seemed to me that opengl wasn't getting linked, so I was moving the link order around in experimentation. The stock configuration has the libraries in the correct order. I apologize for the confustion on this aspect. BTW, the stock configuration provided the same message. I'm involved with the autopilot.sf.net project and we are exploring flightgear integration with our simulator. The helicopter flight model was written by Aaron Kahn and has a VERY realistic hover simulation. Optionally, a flybar component can be introduced into the model for further simulating R/C class helicopters. flight model is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-sim/ This is our focus as we are working on a GPS aided INS system for R/C helicopters and airplanes. The simulator allows us to work on the groundstation, kalman filter and other vehicle systems in virtual reality. The Kalman filter is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/imu-filter/ Navigation prototype is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/controller/ Trammell from the autopilot.sf.net project found an old flightgear-users message that detailed the cygwin build procedure. This email was enough to get flightgear compiling on my system. It seems cygwin is pretty messy with regards to OpenGL and X11 (three sets variations of GL headers!!). I don't know enough about flightgear yet to know how to integrate the flight model... Either internally or as an external driver? Although, I must admit that I have been having too much fun flying and using flightgear and not enough time looking at the code :-) Plib networking also looks attractive. We have a TCP/IP based state server on the sim and a UDP based state server onboard the vehicle. We are working to reconcile them (into UDP due to the nature of our wireless telemetry system) and someone mentioned Plib. Between flightgear and opengc, it would be great to adhere to some sort of open source simulation network standard. our TCP/IP networking is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/state/ Our UDP network is embedded in the onboard filter and ground station at the moment and isn't very modular (... hack ...) I got a little spoiled these past four years doing Java stuff at NextBus./plug I have done mostly Java work for the past 3 years. This has spoiled me in regards to build systems. Switching back to C/C++ multi-platform systems has been a rude awakening... Thanks for the responses on this cygwin issue. Dennis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
On Mon, 10 Feb 2003 11:56:36 -0500, Dennis B. D'Annunzio [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Andy Ross wrote: *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Yes, it seemed to me that opengl wasn't getting linked, so I was moving the link order around in experimentation. The stock configuration has the libraries in the correct order. I apologize for the confustion on this aspect. BTW, the stock configuration provided the same message. I'm involved with the autopilot.sf.net project and we are exploring flightgear integration with our simulator. The helicopter flight model was written by Aaron Kahn and has a VERY realistic hover simulation. Optionally, a flybar component can be introduced into the model for further simulating R/C class helicopters. ..aaah, another dream come true. Thank you and welcome onboard. :-) flight model is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-sim/ This is our focus as we are working on a GPS aided INS system for R/C helicopters and airplanes. The simulator allows us to work on the groundstation, kalman filter and other vehicle systems in virtual reality. The Kalman filter is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/imu-filter/ Navigation prototype is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/controller/ Trammell from the autopilot.sf.net project found an old flightgear-users message that detailed the cygwin build procedure. This email was enough to get flightgear compiling on my system. It seems cygwin is pretty messy with regards to OpenGL and X11 (three sets variations of GL headers!!). I don't know enough about flightgear yet to know how to integrate the flight model... Either internally or as an external driver? Although, ..would an external flight model be easier for you? It can then network with FlightGear both from the same box and from another. I must admit that I have been having too much fun flying and using flightgear and not enough time looking at the code :-) Plib networking also looks attractive. We have a TCP/IP based state server on the sim and a UDP based state server onboard the vehicle. We are working to reconcile them (into UDP due to the nature of our wireless telemetry system) and someone mentioned Plib. Between flightgear and opengc, it would be great to adhere to some sort of open source simulation network standard. our TCP/IP networking is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/state/ ..and your video code? (more or less clueless coder-wannabe looking for a light weight alternative to OpenGL video for FlightGear ;-)) Can your video code be set up to read flight simulation over the network? Like in:... http://dsc.discovery.com/anthology/unsolvedhistory/redbaron/redbaron.html http://www.google.com/search?hl=enie=UTF-8oe=UTF8q=FlightGear+%22Red+Baron%22++Discovery ...which used FlightGear networked to another sim, we don't shoot. Our UDP network is embedded in the onboard filter and ground station at the moment and isn't very modular (... hack ...) I got a little spoiled these past four years doing Java stuff at NextBus./plug I have done mostly Java work for the past 3 years. This has spoiled me in regards to build systems. Switching back to C/C++ multi-platform systems has been a rude awakening... Thanks for the responses on this cygwin issue. Dennis -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
