Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote: Jonathan Polley writes: I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Interesting that this problem exists on OS X also. Could the automatic cleanup of threads at exit() be a Linux extension to Posix threads ??? http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html Well, IRIX doesn't have this problem, so at least it's not not just a Linux extension. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Paul Deppe writes: It looks like it is not possible to specify an --aircraft in system.fgfsrc because the aircraft model is loaded before system.fgfsrc is processed (see program output below). Is this the intended behavior? I thought the processing order was supposed to be 1) preferences.xml, 2) system.fgfsrc, and finally 3) command line. We were planning to drop system.fgfsrc -- I thought we already had, but I guess it's still lurking. The processing order, from memory, is $FG_ROOT/preferences.xml $HOME/.fgfsrc command line All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
David, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson We were planning to drop system.fgfsrc -- I thought we already had, but I guess it's still lurking. The processing order, from memory, is $FG_ROOT/preferences.xml $HOME/.fgfsrc command line I don't fully understand this. Until now, system.fgfsrc was just the equivalent of .fgfsrc on a Windows (and, maybe other) system. Contrary to Unix, you can't name a file .fgfsrc under Windows. So what will Windows users have to do? 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
[Flightgear-devel] Research project in user communities of flight simulators
Dear FlightGear fans developers, This is a short reminder to fill in our questionnaire :-). The University of Munich currently undertakes a research project on flight simulators. Its about users, and in particular (but not only) about users who develop their own add-ons and contributions for FlightGear. The project is purely non-profit and academic, there is no company involved. There is a little lottery among the participants. Heres the questionnaire: http://www.inno-tec.de/simulator/questionnaire_382752.htm Thank you for participating! Best regards, Dr. Joachim Henkel Sandra Thies INNO-TEC Institute for Innovation Research, Technology Management, and Entrepreneurship Munich School of Management Ludwig-Maximilians-University Munich Mr. Dr. Joachim Henkel Mrs. Sandra Thies Kaulbachstr. 45 80539 Munich Germany Tel.: +49 - 89 - 2180-2986 Fax: +49 - 89 - 2180-6284 E-mail: [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem Building CVS FlightGear
I had not updated my copy of the code base for a few weeks, so I grabbed the CVS for plib, SimGear and FlightGear yesterday, and found that Flightgear would not build. This is on cygwin, which I updated to the latest version yesterday, but still on gcc version 2.95.3-10 (cygwin special). I have done a complete rebuild and reinstall of plib, and SimGear, but compiling FlightGear fails: make[3]: Entering directory `/home/Administrator/FGFS/CVS/FlightGear/build/src/Cockpit' source='../../../src/Cockpit/cockpit.cxx' object='cockpit.o' libtool=no \ depfile='.deps/cockpit.Po' tmpdepfile='.deps/cockpit.TPo' \ depmode=gcc /bin/bash ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I../../../src/Cockpit -I../../src/Include -I../../.. -I../../../src -I/usr/local/include -O1 -fno-inline -c -o cockpit.o `test -f '../../../src/Cockpit/cockpit.cxx' || echo '../../../src/Cockpit/'`../../../src/Cockpit/cockpit.cxx In file included from ../../../src/Cockpit/cockpit.hxx:35, from ../../../src/Cockpit/cockpit.cxx:54: ../../../src/Cockpit/hud.hxx: In method `void fgLineList::draw()': ../../../src/Cockpit/hud.hxx:380: implicit declaration of function `int for_each(...)' make[3]: *** [cockpit.o] Error 1 make[3]: Leaving directory `/home/Administrator/FGFS/CVS/FlightGear/build/src/Cockpit' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/Administrator/FGFS/CVS/FlightGear/build/src/Cockpit' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Administrator/FGFS/CVS/FlightGear/build/src' make: *** [all-recursive] Error 1 The only other reference to for_each() in the FlightGear code is in Main/fg_io.cxx, where is has a SG_USING_STD(for_each); before it. I have tried blindly putting this in hud.cxx, but to no avail. Any ideas? Richard Bytheway ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Michael Basler writes: We were planning to drop system.fgfsrc -- I thought we already had, but I guess it's still lurking. The processing order, from memory, is $FG_ROOT/preferences.xml $HOME/.fgfsrc command line I don't fully understand this. Until now, system.fgfsrc was just the equivalent of .fgfsrc on a Windows (and, maybe other) system. Contrary to Unix, you can't name a file .fgfsrc under Windows. So what will Windows users have to do? Oh, I see. In Unix, we have (or had) two files: system.fgfsrc in $FG_ROOT .fgfsrc in $HOME The idea was that system.fgfsrc is system-wide, while .fgfsrc is per-user. For Windows, perhaps we should look for fgfs.cfg in My Documents or wherever (is there any concept of separate user directories yet?). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
David Megginson writes: Paul Deppe writes: It looks like it is not possible to specify an --aircraft in system.fgfsrc because the aircraft model is loaded before system.fgfsrc is processed (see program output below). Is this the intended behavior? I thought the processing order was supposed to be 1) preferences.xml, 2) system.fgfsrc, and finally 3) command line. We were planning to drop system.fgfsrc -- I thought we already had, but I guess it's still lurking. The processing order, from memory, is $FG_ROOT/preferences.xml $HOME/.fgfsrc command line Please don't do this As I pointed out the last time you suggested doing this, on windows the system.fgfsrc file is the same thing as the ~/.fgfsrc file on Unix This is not 'old stale code' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
David, The idea was that system.fgfsrc is system-wide, while .fgfsrc is per-user. For Windows, perhaps we should look for fgfs.cfg in My Documents or wherever (is there any concept of separate user directories yet?). Win XP and 2000 allow management of separate user directories under the Documents and Settings path for saving specific settings and files, and you can even login as a specific user. However, all this is less developed and stringet compared to a Unix system. There is no unique direct equivalent of a $HOME directory under Windows, though. Besides, older Windows variants still in use don't have these directories. Personally I've got most of my user's files just on a separate partition (and all the FlightGear stuff on yet another partition and FS2002 on yet another one and so on). From my POV the mechanism we had with just a single system.fgfsrc in $FG_ROOT would be sufficient for most (all?) Windows users. You still can allow and parse a .fgfsrc under $HOME for Unix users, though. 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] Problem Building CVS FlightGear
Richard Bytheway writes: I have done a complete rebuild and reinstall of plib, and SimGear, but compiling FlightGear fails: ../../../src/Cockpit/hud.hxx:380: implicit declaration of function `int for_each(...)' Hmm... There is no 'for_each()' call in the hud.hxx in the CVS try deleting hud.hxx and issuing a 'cvs up' You probably picked this up from my '2D 3D HUD consolidation' which never made it into CVS Don't really understand why you are having a problem with 'for_each()' though as it is defined in stl_algol.h I guess you could try adding #include algorithm Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Michael Basler writes: Personally I've got most of my user's files just on a separate partition (and all the FlightGear stuff on yet another partition and FS2002 on yet another one and so on). From my POV the mechanism we had with just a single system.fgfsrc in $FG_ROOT would be sufficient for most (all?) Windows users. You still can allow and parse a .fgfsrc under $HOME for Unix users, though. What we probably need to do, then, is remove the old system.fgfsrc code, and instead load a file named system.fgfsrc (or perhaps fgfs.cfg) when a Unix system would load $HOME/.fgfsrc. That should fix the init-order problem. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem Building CVS FlightGear
-Original Message- From: Norman Vine [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 1:15 pm To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Problem Building CVS FlightGear Richard Bytheway writes: I have done a complete rebuild and reinstall of plib, and SimGear, but compiling FlightGear fails: ../../../src/Cockpit/hud.hxx:380: implicit declaration of function `int for_each(...)' Hmm... There is no 'for_each()' call in the hud.hxx in the CVS try deleting hud.hxx and issuing a 'cvs up' You probably picked this up from my '2D 3D HUD consolidation' which never made it into CVS Don't really understand why you are having a problem with 'for_each()' though as it is defined in stl_algol.h I guess you could try adding #include algorithm Norman Deleting the files in /Cockpits/ and re-getting them fixed it. The glitch probably crept in due to my slightly odd way of getting the cvs for FlightGear and SimGear. My local ISP mangles the dns badly enough that I cannot use CVS directly, so I run cvs on a different machine, and then scp across to my local machine. I think I need to look at my scp flags and options to make sure it overwrites files... Thanks. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
--- David Megginson [EMAIL PROTECTED] wrote: The idea was that system.fgfsrc is system-wide, while .fgfsrc is per-user. For Windows, perhaps we should look for fgfs.cfg in My Documents or wherever (is there any concept of separate user directories yet?). $USERPROFILE on WinNT shold resolve to the root of the users home directory. $SYSTEMROOT should resolve to the operating system root directory. Many cross platform apps (X-Plane as an example) use the OS root directory ($SYSTEMROOT) to store stuff. I don't know if this is good practice (I don't care for it personally), but nonetheless. IMHO, it would be nice to see default config file names and locations be names that would work across all platforms and to see that they land in places on a given OS that have analogies to each other. Better, IMHO, would be to keep default configuration info encapsulated under the application root somewhere, with command line options for specifying alternate locations and/or names. I guess this flies in the face of what applications typically do on a UNIX machine. Tony = ___ 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] Continued Cygwin problems
Hello again, Definitely getting the feeling that Cygwin doesn't like me. Linux builds and runs FlightGear with no problem, and Norman's fgfs.exe runs nicely here under Win98. But Cygwin keeps falling short. Started with updating todays cvs of base package, SimGear, and FlightGear. Have plib of 11/26/02 to avoid entanglement with the js changes of recent days. Ran autogen.sh, configure, make clean, make and make install on all packages. With only the 1-line patch to SimGear's configure.am to bypass the X11 tree, compilation of all parts was successful. Attempting to run brought back that familiar segmentation fault. For variety, the leadin to the fault was a bit different. The following lines were copied from scribbled notes at the other machine scheduling needed tiles for -122.358 37.6117 load() base = /cygdrive/d/FlightGear/Scenery loading tile /cygdrive/d/FlightGear/Scenery/w010n00/w001n00/2938503 and then the inevitable stackdump. Looks like it knew the default area, but wound up looking for the tiles in the all zero coord. leaf. How did it get lost? The other question is how do I resolve addresses to symbols under Cygwin? The stack dump is not all that useful to me in only hex format. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Continued Cygwin problems
William Earnest writes: Definitely getting the feeling that Cygwin doesn't like me. For variety, the leadin to the fault was a bit different. The following lines were copied from scribbled notes at the other machine scheduling needed tiles for -122.358 37.6117 load() base = /cygdrive/d/FlightGear/Scenery loading tile /cygdrive/d/FlightGear/Scenery/w010n00/w001n00/2938503 Hmm... I just saw this the other day too ... are you running this from a Cygwin shell ? what is % echo $FGROOT The other question is how do I resolve addresses to symbols under Cygwin? The stack dump is not all that useful to me in only hex format. I have never found this file very useful Try running fgfs under gdb % gdb $FULLPATH_TO_fgfs.exe This should help Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Continued Cygwin problems
Norman Vine wrote: William Earnest writes: The other question is how do I resolve addresses to symbols under Cygwin? The stack dump is not all that useful to me in only hex format. I have never found this file very useful but you can use addr2line to decode the hex numbers Its use is allways a bit confusing to me basically % addr2line -e $FULL_PATH_TO_EXE -f hex number to decode I think you need to add a 0x prefix % info addr2line Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Continued Cygwin problems
Norman Vine wrote: Norman Vine wrote: William Earnest writes: The other question is how do I resolve addresses to symbols under Cygwin? The stack dump is not all that useful to me in only hex format. I have never found this file very useful but you can use addr2line to decode the hex numbers Its use is allways a bit confusing to me basically % addr2line -e $FULL_PATH_TO_EXE -f hex number to decode I think you need to add a 0x prefix % info addr2line Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Norman, Thanks for the hints. Will try addr2line shortly. I had set the fg-root in my .fgfsrc, and it was being used throughout the startup. I also had an entry for the scenery directory, and hadn't edited it to match, but fixing that does not change the odd tile value. In any case, I would expect to start up sitting on water with no such tile found. All the rest of the startup dialog has reasonable values and no complaints. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? Best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? Doing a google on rsync cygwin pulled up this post that claims that it works normally out of the box. You have to build it yourself, or did as of a year ago anyway. http://www.cygwin.com/ml/cygwin-apps/2001-01/msg00021.html The rsync distribution is tiny -- less than half the size of metakit. And it has zero meaningful dependencies (file system access and the sockets API). I don't see any particular reason we can't require it as part of the SimGear build. Even so, there's still no reason fgfs can't try to spawn an rsync on the assumption that it exists on the users path. If it fails it fails; having no scenery is a non-fatal error condition that the user would have had to deal with anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] panel.cxx
I'm compiling FG from CVS sources on MSVC .NET. As you can imagine, it didn't exactly work out of the box. ;) I'll post diffs after I get it running, but for now here's one particular bug that should be cross-platform compatible *grin* panel.cxx line 560: bool FGPanel::doMouseAction (int button, int updown, int x, int y) should return something, and it doesn't. I just stuck a return false at the end, let me know if this is not kosher for any reason, or if the function decl. should be changed. --nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Andy Ross writes: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? Doing a google on rsync cygwin pulled up this post that claims that it works normally out of the box. rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default Until then or until we have the equivalant IMHO terrasync should be an 'option' Shouldn't be to hard to program equivalent functionality using the PLIB net routines though if someone was so inclined. or perhaps we could substitute Unison http://www.cis.upenn.edu/~bcpierce/unison/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default How about this one: http://winrsync.sunsite.dk/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Erik Hofman writes: Norman Vine wrote: rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default How about this one: http://winrsync.sunsite.dk/ Hmmm Just a couple of dependencies :-) Norman a.. WINrsync_latest.exe ~2.7M Windows installer, includes PHP-GTK and rsync. Will not interrupt other installs of PHP-GTK, rsync, cygwin etc. a.. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
* [EMAIL PROTECTED] (Andy Ross) [2002.12.04 13:21]: I just tried this last night. Curt, this rocks. I haven't tried it, but I can't wait to do so. I think you have to give serious thought to enabling this by default, either by adding it to the fgfs binary or by having fgfs spawn it as a child. It turns the job of downloading, installing and updating scenery from an annoying sysadmin chore into a trivial noop that your proverbial grandmother could use. This is a huge, huge win. Hiding it inside a separate executable and requiring special command line arguments is doing casual users a major disservice -- they *want* this feature. (Sure, some will want the ability to disable it. But the majority of users will see a lot of benefit from having it on by default.) http://librsync.samba.org/ It's LGPL'd and pre-1.0. Here's their current TODO list from CVS: http://cvs.samba.org/cgi-bin/cvsweb/librsync/TODO?rev=1.31content-type=text/x-cvsweb-markup Related to the above, you'll probably want to segregate a release scenery directory from the development scenery to prevent incompatible changes from being pushed to users without current code. I agree. It occurs to me that if fgfs tries to load a scenery tile while rsync is still pulling, you will get corrupt tile and (worst case) crash the tile parser. Is there a need for locking or protection against this sort of thing? Just a mail-spool-style dot lock should be sufficient -- if FlightGear sees a .terrasync-in-progress file, it can refuse to load the directory. [This is the cue for someone to jump in with a discussion about all the dangers and pitfalls of different locking mechanisms on different filesystems.] Apologies if a feature like this is already in there, I haven't read the code. Locking an entire directory would be bad thing. We would want to do per-file locks. The simplest cross-platform solution is a .lock file for a given file. Using flock or equivalent would be a bit more complicated, but I'm not familiar with anything other than Linux. Couldn't we have a simple filelock function in SG with a bunch of #ifdef's each platform's implementation? I assume most OSes have the same abilities -- exclusive write, read, or both. Again, magnificent feature. I love it. Yes, I can't wait to play with it. -- Cameron Moore __END__ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
* [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. Are you playing with FG at work? :-) -- Cameron Moore [ I have an inferiority complex. But it's not a very good one. ] ___ 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++
Re: [Flightgear-devel] terrasync
Andy Ross writes: Norman Vine wrote: rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default Why? It doesn't hurt anything to try spawning a non-existant program. It just fails to load any scenery, which is exactly the behavior you want. Is there something that will actually break on windows if we make this the default? I can't see anything. DOH Of course you are right no rsync no action doh :-) But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! Of course this doen't really matter to you or myself in that we can compile in or own defaults, I am thinking of the naive user who thinks that they have caught a virus because their fire wall alarm starts ringing as soon as FGFS is fired up :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote:
But the question remains how best to get the threaded tile manager
working and 'behaving' under Win32 and OS X.
Does this patch work by any chance?
Erik
--- /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.cxxSat Sep 7
04:58:20 2002
+++ SimGear/simgear/threads/SGThread.cxxWed Dec 4 21:29:37 2002
@@ -19,18 +19,20 @@
void
SGThread::set_cancel( cancel_t mode )
{
+int oldstate;
+
switch (mode)
{
case CANCEL_DISABLE:
- pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, 0 );
+ pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, oldstate );
break;
case CANCEL_DEFERRED:
- pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, oldstate );
break;
case CANCEL_IMMEDIATE:
- pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, oldstate );
break;
default:
break;
Re: [Flightgear-devel] Voice ATIS
On 12/3/02 at 11:05 PM Julian Foad wrote: David Luff wrote: I've managed to get canned voice ATIS going. Wow! Brilliant. It really works! It sounds about like I'd expect, too (e.g. the 8 kHz-ness). OK, Thanks for testing this. This is now in CVS. A base update is also required to hear it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] terrasync
Andy, [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Ross Sent: Wednesday, December 04, 2002 8:43 PM Doing a google on rsync cygwin pulled up this post that claims that it works normally out of the box. You have to build it yourself, or did as of a year ago anyway. http://www.cygwin.com/ml/cygwin-apps/2001-01/msg00021.html rsync comes with Cygwin and can be installed via the installer. This way I can run terrasync from a Cygwin bash shell (runs pretty well). However, this would require any Windows user to install Cygwin first, which I am sure not any user is fond of just for running the FlightGear binary. And as Norman pointed out there is no native rsync delivered with Windows (any flavor AFAIK). One ugly solution might be to provide just the rsync.exe, but I don't know if this works (it would require the cygwin dll, at least). Plus this might cause licensing troubles. Switching to http as Christian pointed out would be one clean solution, although I can't judge how hard it's to realize. 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] terrasync
Cameron Moore wrote: * [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. Are you playing with FG at work? :-) No. And chances are my firewall at home does work... But I don't know how the firewall at my univeristy is configured (and I'm allowed to use FGFS there...) Anyway, I can understand anybody who denies as much as possible in the firewall config (doesn't matter if it's at work or at home). And opening a port just for FGFS for a protocoll that can be replaced with a protocol that passes through most firewalls flawlessly doesn't seem like good practice. Oh, and changing to HTTP would allow proxies to cache the scenery... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! That's a fair point, although as long as we aren't transmitting any data I don't see any ethical problems. Some users on per-minute dialup might not want FlightGear to fire up their modem. But certainly we want this to be as easy as possible. To us, it's only a major convenience. But to a casual user, it turns FlightGear from a bay-area only demo into a whole-world flight simulator. That's a huge win. So if it's not the raw default, it needs to be a trivially simple switch that any user can throw. I'd be happy with something like a --auto-scenery argument (or better yet, a runtime menu option). But having to run terragear manually and specify an atlas argument to fgfs is too much complexity for the casual downloader. These are the people that can most benefit from this feature; and they get a *lot* of benefit from it. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGFS starting terrasync
Norman says: But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! Of course this doen't really matter to you or myself in that we can compile in or own defaults, I am thinking of the naive user who thinks that they have caught a virus because their fire wall alarm starts ringing as soon as FGFS is fired up :-) Yes, it would be nice to make it configuration item that decides whether it is fired up, together with a menu item that manually starts it. As I see it, the most important thing is to have terrasync somehow detect that FGFS has finished execution and exit cleanly after the current rsync batch is completed. It also needs to check for other terrasync sessions when started and play nice with them somehow. This could, for example, really shrink the base package. The scenery only contains the actual airports in the bay area, and the textures are only those needed to render the airport tiles. If we get our materials colors reasonable, the loader can pick up scenery files for a given tile and then collect any necessary textures afterwards. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Andy Ross writes: Norman Vine wrote: But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! So if it's not the raw default, it needs to be a trivially simple switch that any user can throw. I'd be happy with something like a --auto-scenery argument (or better yet, a runtime menu option). But having to run terragear manually and specify an atlas argument to fgfs is too much complexity for the casual downloader. These are the people that can most benefit from this feature; and they get a *lot* of benefit from it. I agree completely One thing we want to get absolutely right is making sure that it is as easy to stop the daemon as it was to start it up :-) We need to make sure it exits() when FGFS exits() too Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Erik Hofman writes: Norman Vine wrote: But the question remains how best to get the threaded tile manager working and 'behaving' under Win32 and OS X. Does this patch work by any chance? It seems to fix a minor problem with my patch i.e. FGFS printed a failed assertion is sgThread at exit and this patch gets rif of that but FGFS still won't exit with out a 'ctrl-c' or other forced sig quit with the existing static FGTileManager whereas it exits with a dynamically allocated one that automagically calls its destructor at exit time Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Dear All,
oops, pardon moi ... RE:MSVC6 Update - continued ...
This i added, explicily, to fg_init.cxx
// Next check the 'root' for a system.fgfsrc file
if ( aircraft.empty() ) {
// Check for $fg_root/system.fgfsrc
SGPath config( globals-get_fg_root() );
config.append( system.fgfsrc );
aircraft = fgScanForOption( --aircraft=, config.str() );
}
in the fgInitFGAircraft() service ...
As i intimated in a README.msvc6 i sent to Curt, there seems
some BIG DIFFERENCE in environment variables. The CygWin
'attempts' to re-create the unix 'needed' environment variables,
and thus MSVC? user are quite perplexed. What is THIS?
Look, if when the 'system' loads, there is a thing called ABC
created in the runtime environment, great. But in windows we
have 'some' control on this. There is NO automatic $(HOME)
thingy, unless (perhaps?) you are in the WINNT stream? Or
you REALLY want it created!
This 'dependance' on some RUNTIME creation has always
irked me. If you want an runtime application to 'see' something,
tell it, NOT the 'world', what you want. That is each user will
'run' the application with the information it requires, including
what folders to look in ... there are NO 'global' folders ... for
me, anyway ...
To say suggest My Documents, instead of Mes
Documents, is to not yet grasped the complexity of 'who-am-
i combined with 'where-am-i', it is just too big ... language -
pah!
It really seems sufficient that there is ONE 'system' file that
fgfs loads, if it exists, and that is good. What are we missing?
Thus -
We were planning to drop system.fgfsrc -- I thought
we already had, ..
flies directly in the face of this. What is FGFS doing?
Hope this helps ...
Geoff.
PS: Curt, did you not get my README.msvc6? Or you do
not feel it should be in the CVS just yet?
pps:
Dear David,
Oh, I see. In Unix, we have (or had) two files:
system.fgfsrc in $FG_ROOT
.fgfsrc in $HOME
The idea was that system.fgfsrc is system-wide, while .fgfsrc is
per-user. For Windows, perhaps we should look for fgfs.cfg in My
Documents or wherever (is there any concept of separate user
directories yet?).
Yes, windows, or as sometimes written with an embedded '$' sign,
has or has NOT 'separate user space'. In my single home system,
i reduce all this user stuff to me - i am the user - no one else ...
in the NT vain, they make it 'important', but it can still be reduced.
That means $(HOME) has to end homesystem for .fgfsrc
to work, or in windows use %HOME%, but i digress ...
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Geoff McLane writes: PS: Curt, did you not get my README.msvc6? Or you do not feel it should be in the CVS just yet? Hmmm, I don't recall, you probably want to send it again. If I did get it, it is now very buried in my email pile. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Michael Basler wrote: One ugly solution might be to provide just the rsync.exe, but I don't know if this works (it would require the cygwin dll, at least). Plus this might cause licensing troubles. Why not? I can't speak to whether it works with (only) the cygwin DLL, but there's nothing wrong IMHO with shipping required binaries in a binary distribution. Does the windows binary currently ship a metakit DLL, or link it statically? This isn't much different. Again, rsync is a very small program. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Andy Ross writes: Michael Basler wrote: One ugly solution might be to provide just the rsync.exe, but I don't know if this works (it would require the cygwin dll, at least). Plus this might cause licensing troubles. Why not? I can't speak to whether it works with (only) the cygwin DLL, but there's nothing wrong IMHO with shipping required binaries in a binary distribution. Does the windows binary currently ship a metakit DLL, or link it statically? This isn't much different. Again, rsync is a very small program. I don't think we want to ship the cygwin dll as multiple copies / versions of this dll installed on the same machine is a major PITA. Never mind the Cygwin licensing that requires us to keep the source for the DLLs we ship available on our servers for 3 years. If a windows user wants rsync functionality they can install it from the Cygwin distribution channels easily enough. If someone was to volunteer to handle all the help-desk inquiries as to why Cygwin programs aren't working I could be persuaded otherwise :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Wed, 2002-12-04 at 12:47, Christian Mayer wrote: Cameron Moore wrote: * [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. Are you playing with FG at work? :-) No. And chances are my firewall at home does work... But I don't know how the firewall at my univeristy is configured (and I'm allowed to use FGFS there...) Anyway, I can understand anybody who denies as much as possible in the firewall config (doesn't matter if it's at work or at home). And opening a port just for FGFS for a protocoll that can be replaced with a protocol that passes through most firewalls flawlessly doesn't seem like good practice. Oh, and changing to HTTP would allow proxies to cache the scenery... Except, as Curt has already pointed out, rsync is more than just a file transfer protocol ... its functionality would need to be duplicated in FG/SG/plib before http could be used. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Wed, 2002-12-04 at 12:33, Norman Vine wrote: Andy Ross writes: Norman Vine wrote: rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default Why? It doesn't hurt anything to try spawning a non-existant program. It just fails to load any scenery, which is exactly the behavior you want. Is there something that will actually break on windows if we make this the default? I can't see anything. DOH Of course you are right no rsync no action doh :-) But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! Here, here. Of course this doen't really matter to you or myself in that we can compile in or own defaults, I am thinking of the naive user who thinks that they have caught a virus because their fire wall alarm starts ringing as soon as FGFS is fired up :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
I think you have to give serious thought to enabling this by default, either by adding it to the fgfs binary or by having fgfs spawn it as a child. [...] Spawning a child might be a nice option, because it eases running the task asynchronously - anything different is probably not an option (TM ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS starting terrasync
Alex, This could, for example, really shrink the base package. The scenery only contains the actual airports in the bay area, and the textures are only those needed to render the airport tiles. I think ypu are perverting the ideea of a small base package. A small package is useful for those who have very limited network access because it cuts down download/online times. If you reduce the base package that much these people get forced to have their modem online most of the time they are trying/flying FlightGear. I believe this does not serve very much, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Not that my input means diddly ... but YES. I had the exact same thought. Wouldn't it be great it the terrasync util could be pointed at an http server that could stream data back. Simple, well known type of service. Opens the door to random individuals hosting scenery even ? Tony --- Christian Mayer [EMAIL PROTECTED] wrote: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. CU, Christian = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fixes for parallel/SMP make compilation
I've libtoolized the makefiles for current CVS for SimGear and FlightGear. This
allows GNU make to properly handle the dependencies for SMP (parallel) compile.
This naturally speeds up compiles significantly. Does anyone want the diffs?
--
Bryon Roche
Professional {Developer,Guru,Mad Scientist}
[EMAIL PROTECTED]
PGP Key Fingerprint: FE0D EC23 6464 726A CD54 48D3 04AD 86FE 6878 ABD5
Fortuna est caeca
msg10188/pgp0.pgp
Description: PGP signature
Re: [Flightgear-devel] WIN32 threaded binary
On Wednesday, December 4, 2002, at 03:00 AM, Erik Hofman wrote: Norman Vine wrote: Jonathan Polley writes: I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Interesting that this problem exists on OS X also. Could the automatic cleanup of threads at exit() be a Linux extension to Posix threads ??? http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html Well, IRIX doesn't have this problem, so at least it's not not just a Linux extension. Erik Actually, MacOS X has had some known issues with pthreads, although 10.2 is much better than 10.1. Although I can now build with threading, using ESC hangs at the end. If I select the Quit menu item, it shuts down just fine. I would expect that the behavior of exit() is very well defined and, in my case, OS X's implementation is still lacking. I'll try the updates out this weekend. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
