RE: [Flightgear-devel] Building on Cygwin
I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Thereafter, FGFS compiles and runs under Cygwin. I'm not using Andy's libs, but those built by Norman, with a couple of tweaks which have been listed recently (although these may not now be needed, since OpenAl has reportedly fixed the problems). Your errors seem to be lib-related so perhaps the solution lies there. Norman's libs are available at: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Regards, Vivian Thanks for the pointer to the Norman's libs. I had been looking for those but could not find them anywhere. It appears that it is working now. How are Andy's libs meant to be used? One point I have discovered, is that (on Cygwin at least) the shortcut to your home directory, ~/, doesn't seem to get parsed properly when setting fg-root: [EMAIL PROTECTED] ~ $ fgfs --fg-root=~/FGFS/FlightGear/data/ Base package check failed ... Found version [none] at: ~/FGFS/FlightGear/data/ Please upgrade to version: 0.9.8 [EMAIL PROTECTED] ~ $ fgfs --fg-root=/home/Richard.Bytheway/FGFS/FlightGear/data/ ...(normal startup) Thanks again. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on Cygwin
Richard Bytheway wrote I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Thereafter, FGFS compiles and runs under Cygwin. I'm not using Andy's libs, but those built by Norman, with a couple of tweaks which have been listed recently (although these may not now be needed, since OpenAl has reportedly fixed the problems). Your errors seem to be lib-related so perhaps the solution lies there. Norman's libs are available at: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Regards, Vivian Thanks for the pointer to the Norman's libs. I had been looking for those but could not find them anywhere. It appears that it is working now. How are Andy's libs meant to be used? Hmmm ... never made them work, and I'd quite forgotten them. One point I have discovered, is that (on Cygwin at least) the shortcut to your home directory, ~/, doesn't seem to get parsed properly when setting fg-root: [EMAIL PROTECTED] ~ $ fgfs --fg-root=~/FGFS/FlightGear/data/ Base package check failed ... Found version [none] at: ~/FGFS/FlightGear/data/ Please upgrade to version: 0.9.8 [EMAIL PROTECTED] ~ $ fgfs --fg-root=/home/Richard.Bytheway/FGFS/FlightGear/data/ ...(normal startup) Never noticed that; I keep FGFS at a higher level, but now that you mention it, so it does. It's not a problem, but we ought to record all this somewhere. We seem to go through some Cygwin drama every major update. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building on Cygwin
Vivian Meazza wrote: Never noticed that; I keep FGFS at a higher level, but now that you mention it, so it does. It's not a problem, but we ought to record all this somewhere. We seem to go through some Cygwin drama every major update. That's what Wiki's are for: http://www.seedwiki.com/wiki/flight_gear/flight_gear_developer_documentation.html?wpid=123227 Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building on Cygwin
From: Andy Ross Vivian Meazza wrote: I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Goodness, that brings back memories. The near and far keywords are holdovers from 16 bit DOS compilers. They are still defined (as noops) for compatibility with ancient code. Basically, the 8086 had 16 bit registers, so a single instruction could only address memory within a 64k range (which was defined by the appropriate segment register). This 16 bit object was called a near pointer. If you wanted to see things outside that range, you needed to use multiple instructions to first load a segment register and then execute the load. (This really wasn't so insane if you think about it -- the original idea for a typical was that all the code would go in a 64k segment, the heap data in another and the stack in a third; this 192k address space was larger than that available to Unix programs running on a PDP-11, for instance. It seemed like a good solution at the time. It didn't become a problem until typical interactive PC applications started needed hundreds of kilobytes of address space. For 1976, it was actually pretty elegant.) I can remember the pain too :-). Actually it was a limitation of what could be made for hardware at the time (which I think you already know). The 16 bit address register (max 64k value) was a pretty cool step up, and quite a dramatic improvement over the 8 bit especially in micro chips. (As was the 32 later). The addressing scheme was merely a comprimise for what could be done. The orginization of IBM PC Bios layout on the other hand was a design choice based on expectations of what would be possible for the architecture in 1980 vision. And that sure caused some pain! Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on Cygwin
Erik Hofman wrote Vivian Meazza wrote: Never noticed that; I keep FGFS at a higher level, but now that you mention it, so it does. It's not a problem, but we ought to record all this somewhere. We seem to go through some Cygwin drama every major update. That's what Wiki's are for: http://www.seedwiki.com/wiki/flight_gear/flight_gear_developer_documentati on.html?wpid=123227 Of course, in keeping with custom, when I wrote 'we', I meant 'someone else' :-) Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on Cygwin
I have been building FlightGear in Cygwin since the 0.6 days, but for the past few months I have not been able to get a build to complete. I have had, and have overcome problems with OpenAL in the past, but they seem to have resurfaced. In the absence of any useful information from me (like files it fails on, and error messages), does anyone have a general (but up-to-date) guide to building FlightGear on Cygwin, or even a list of common problems and solutions? I shall gather some hard evidence tonight and post it tomorrow if needed. Thanks, Richard OK, I have made progress past the OpenAL hiccups. First I tried building OpenAL CVS, but that did not appear to work. So I found the OpenAL build by Andy Ross (http://plausible.org/andy/fgfs-mingw-libs.tar.gz) which appears to do the trick. I then had to tweak Main/renderer.cxx, lines 890 onwards to rename near and far which were causing a problem. I used qnear and qfar in lines 890, 891, 904, 913 and 914 and compilation runs nearly to the end. The final link still fails though. Error is pasted below, can anyone shed any light? Richard Making all in Main make[2]: Entering directory `/home/richard.bytheway/FGFS/FlightGear/build/src/Main' g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT -L/usr/local/lib -o fgfs.exe bootstrap.o ../../src/Main/libMai n.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.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/libExternalN et.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBS im/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/libSPFDM.a .. /../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a .. /../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scen ery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlaye r/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic .a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtim ing -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructu re -lsgenvironment -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut32 -lglu32 -lopengl32 - luser32 -lgdi32 -lALut -lopenal32 -lwinmm -ldsound -ldxguid -lole32 ../../src/Main/libMain.a(main.o)(.text+0x35d0): In function `_Z10fgMainInitiPPc': /usr/include/c++/3.3.3/bits/char_traits.h:143: undefined reference to `_aircraftdir_' ../../src/Main/libMain.a(fg_props.o)(.text+0x17d5): In function `_Z14getAircraftDirv': /usr/include/c++/3.3.3/bits/basic_string.h:717: undefined reference to `_aircraftdir_' ../../src/Main/libMain.a(fg_props.o)(.text+0x180d): In function `_Z14setAircraftDirPKc': /usr/include/c++/3.3.3/bits/char_traits.h:143: undefined reference to `_aircraftdir_' ../../src/Main/libMain.a(fg_init.o)(.text+0x11088): In function `_Z9fgInitFDMv': /usr/include/c++/3.3.3/bits/basic_string.h:361: undefined reference to `_aircraftdir_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0x981): In function `_ZN9FGLaRCsim6updateEd': /home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../source/src/FDM/LaRCsim/LaRCsim.cxx:406: undefined reference to `_aircraft_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0xad0):/home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../ source/src/FDM/LaRCsim/LaRCsim.cxx:324: undefined reference to `_aircraft_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0xce2):/home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../ source/src/FDM/LaRCsim/LaRCsim.cxx:394: undefined reference to `_aircraft_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0xd11):/home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../ source/src/FDM/LaRCsim/LaRCsim.cxx:395: undefined reference to `_aircraft_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0xd91):/home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../ source/src/FDM/LaRCsim/LaRCsim.cxx:338: undefined reference to `_aircraft_' ../../src/FDM/LaRCsim/libLaRCsim.a(LaRCsim.o)(.text+0xdaa):/home/richard.bytheway/FGFS/FlightGear/build/src/FDM/LaRCsim/../../../../ source/src/FDM/LaRCsim/LaRCsim.cxx:344: more undefined references to `_aircraft_' follow ../../src/FDM/LaRCsim/libLaRCsim.a(ls_step.o)(.text+0x23): In function
RE: [Flightgear-devel] Building on Cygwin
Richard Bytheway I have been building FlightGear in Cygwin since the 0.6 days, but for the past few months I have not been able to get a build to complete. I have had, and have overcome problems with OpenAL in the past, but they seem to have resurfaced. In the absence of any useful information from me (like files it fails on, and error messages), does anyone have a general (but up-to-date) guide to building FlightGear on Cygwin, or even a list of common problems and solutions? I shall gather some hard evidence tonight and post it tomorrow if needed. Thanks, Richard OK, I have made progress past the OpenAL hiccups. First I tried building OpenAL CVS, but that did not appear to work. So I found the OpenAL build by Andy Ross (http://plausible.org/andy/fgfs-mingw- libs.tar.gz) which appears to do the trick. I then had to tweak Main/renderer.cxx, lines 890 onwards to rename near and far which were causing a problem. I used qnear and qfar in lines 890, 891, 904, 913 and 914 and compilation runs nearly to the end. The final link still fails though. Error is pasted below, can anyone shed any light? I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Thereafter, FGFS compiles and runs under Cygwin. I'm not using Andy's libs, but those built by Norman, with a couple of tweaks which have been listed recently (although these may not now be needed, since OpenAl has reportedly fixed the problems). Your errors seem to be lib-related so perhaps the solution lies there. Norman's libs are available at: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building on Cygwin
Vivian Meazza wrote: I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Goodness, that brings back memories. The near and far keywords are holdovers from 16 bit DOS compilers. They are still defined (as noops) for compatibility with ancient code. Basically, the 8086 had 16 bit registers, so a single instruction could only address memory within a 64k range (which was defined by the appropriate segment register). This 16 bit object was called a near pointer. If you wanted to see things outside that range, you needed to use multiple instructions to first load a segment register and then execute the load. (This really wasn't so insane if you think about it -- the original idea for a typical was that all the code would go in a 64k segment, the heap data in another and the stack in a third; this 192k address space was larger than that available to Unix programs running on a PDP-11, for instance. It seemed like a good solution at the time. It didn't become a problem until typical interactive PC applications started needed hundreds of kilobytes of address space. For 1976, it was actually pretty elegant.) In C, this notion was implemented by using a far pointer -- a 32 bit object consisting of both a segment value and a pointer. The compiler would know which instruction sequence to used based on the type of the pointer it was using. Anyway, yes: near and far aren't portably useful as variable names if you want to compile on windows. I'm sure the MSVC headers have the same problem that the cygwin one does. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on Cygwin
Andy Ross wrote: Vivian Meazza wrote: I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Goodness, that brings back memories. The near and far keywords are holdovers from 16 bit DOS compilers. They are still defined (as noops) for compatibility with ancient code. Basically, the 8086 had 16 bit registers, so a single instruction could only address memory within a 64k range (which was defined by the appropriate segment register). This 16 bit object was called a near pointer. If you wanted to see things outside that range, you needed to use multiple instructions to first load a segment register and then execute the load. (This really wasn't so insane if you think about it -- the original idea for a typical was that all the code would go in a 64k segment, the heap data in another and the stack in a third; this 192k address space was larger than that available to Unix programs running on a PDP-11, for instance. It seemed like a good solution at the time. It didn't become a problem until typical interactive PC applications started needed hundreds of kilobytes of address space. For 1976, it was actually pretty elegant.) In C, this notion was implemented by using a far pointer -- a 32 bit object consisting of both a segment value and a pointer. The compiler would know which instruction sequence to used based on the type of the pointer it was using. Anyway, yes: near and far aren't portably useful as variable names if you want to compile on windows. I'm sure the MSVC headers have the same problem that the cygwin one does. I'm amazed that you can remember all that! And so long ago! Very interesting explanation. Thanks. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on Cygwin
Vivian Meazza writes: Andy Ross wrote: Vivian Meazza wrote: I have the same problem with Main/renderer.cxx. Your solution (or one very like it) solves the problem. I guess near/far are reserved words in Cygwin? Goodness, that brings back memories. The near and far keywords are holdovers from 16 bit DOS compilers. They are still defined (as noops) for compatibility with ancient code. I'm amazed that you can remember all that! And so long ago! Very interesting explanation. Thanks. That kind of pain is not easily forgotten :-) Seriously 'near' and 'far' should be considered 'reserved words' that belong to the prehistoric days and be permanently banned from contemporary use Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Building on cygwin...
The cygwin is the lates from the web site with everything installed, I can compile/build things with it without any problems. My main problem is that plib requires glut to compile / build, which isn't in the cygwin installation. I have tried using mesa or freeglut but both of these fail to build and seem very broken, a pointer to a version of glut that works would be a great help. 1. By default, Cygwin installs only a minimum of packages excluding most of the development stuff. Check that all these including the OpenGL package are installed. (Unfortunately I don't have a complete list at hand.) I doin't have the very latest version, but in my case Glut is included (chek for glut.h under /usr/include/GL). 2. Do not install any X packages as X comes with its own OpenGL which interferes with FlightGear stuff. Otherwise Cygwin works very fine for me. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building on cygwin...
The cygwin is the lates from the web site with everything installed, I can compile/build things with it without any problems. My main problem is that plib requires glut to compile / build, which isn't in the cygwin installation. I have tried using mesa or freeglut but both of these fail to build and seem very broken, a pointer to a version of glut that works would be a great help. cheers. I'm using glut-3.7. Try http://www.opengl.org/developers/code/glut_examples/progs.html You might have to surf around a bit to find the download section. it's been a while and I can't remember the exact URL but this should get you in the neighborhood Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building on cygwin...
Michael Basler wrote: 1. By default, Cygwin installs only a minimum of packages excluding most of the development stuff. Check that all these including the OpenGL package are installed. (Unfortunately I don't have a complete list at hand.) I doin't have the very latest version, but in my case Glut is included (chek for glut.h under /usr/include/GL). I can't figure out why I seemed to have all the rest of the opengl stuff except glut.h in /usr/include/GL ? I d/l'd the opengl package again and installed it, after a day and a half this has fixed the problem, the build was perfect. Thanks to all who helped. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building on cygwin...
Subject: [Flightgear-devel] Building on cygwin... I'm interested in helping out on the Flightgear project, specifically the multiplayer networking stuff if it hasn't already been done, but I'm having a lot of trouble trying to get the software to build on cygwin. Does anyone have any pointers as to how to get it to build using cygwin? I've got builds on cygwin and linux, but need a little more info to help you. Such as: Is the cygwin installation solid? Are all the pieces there? Can you build other programs? Have you downloaded all the prerequisites - plib, simgear, etc. A little more detail on the types of problems and I'm sure someone will be able to help And don't forget RTFM -- see the install docs on the website Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
