Re: [Flightgear-devel] terrasync
On Thu, 5 Dec 2002, Cameron Moore wrote: I guess _my_ question in regard to rsync is how much would rsync actually help in our case. If a tile is changed -- say we fixed a runway or something -- would a diff accomplish anything since we have binary scenery files that are also gzipped? Would the rolling checksums that rsync does all end up being different, so we are always downloading the entire file anyway? If this is the case, then rsync's main advantage is worthless to us. Having used rsync to transfer 650MB cd images I can say that it DOES help a lot - having it download the new one in 10 minutes after a few minor changes at the other end is rather impressive on a 512Kb/s DSL line. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] model animation bug
Jim Wilson writes: It looks like the animation code fails to move a group object if one of it's subobjects is identified in a object selection tag. When you add a new animation, the animation code slices a new ssgBranch of some kind between the existing node and its parent -- that should never cause any problem. If, however, you specify several nodes for the same animation, all but the first will be moved to the new ssgBranch. So if you have animation typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name object-nameBar/object-name ... /animation The Bar object will be be reparented first to the ssgBranch above Foo, then to the ssgBranch above Hack (losing the 'translate' animation). You can work around this problem with animation typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name ... /animation animation typerotate/type object-nameBar/object-name ... /animation If you specify only one object-name, the object should always stay in the same group. That's slightly less efficient, but if you picture the way the animation code modifies the tree, you'll be able to figure out when you really need it and when you don't. 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] PA-28-161 C-FBJO
Ryan Larson writes: I flew an Arrow-III up to Minneapolis and back this past weekend. Even with a CAS of 135 kts, I had a GS of about 80-88 kts the whole way up to Minneapolis at 6000 feet because of a cold front moving through. On the way back, I had a great tailwind and at 9000 feet I was at 130 kts CAS and 194 kts GS. With a top speed of 217 kts GS on a descent from 9000 to 7000 feet. Interesting. That's why people will pay for an extra few knots -- if you're flying into a 60kt headwind, a 120kt airplane is 1.5 times as fast as a 100kt airplane, for example. If you have an idea of what types of numbers you would like to get in terms of performance data.. I can try and get some on the Arrow and an Archer. I also have manuals for the Arrow and the Archer if that would be helpful. Do we have a central place we could store this stuff? Jon collects aero data at the JSBSim site. Anyway.. congrats on the purchase. It looks like a nice plane.. wish I had the guts to pull the trigger and buy my own plane, but with the job market the way it is.. I can't afford to make that purchase right now. Yes, I'm nervous as well, but you can look at it this way: a VFR 1960's PA-28-140 doesn't cost much more than new minivan, either to buy or to operate. 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] terrasync
Cameron Moore writes: The biggest difference between rsync and HTTP is that rsync downloads diffs[1] while HTTP must download the entire file. This is a big plus for people with slow connections. I guess _my_ question in regard to rsync is how much would rsync actually help in our case. If a tile is changed -- say we fixed a runway or something -- would a diff accomplish anything since we have binary scenery files that are also gzipped? Would the rolling checksums that rsync does all end up being different, so we are always downloading the entire file anyway? If this is the case, then rsync's main advantage is worthless to us. Agreed -- it is. 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] PA-28-161 C-FBJO
Cameron Moore writes: For those of you that haven't been here for long, the same David Megginson made the following post back in April about his disappointing first training flight: ... I'd say that there's a 55% chance I won't continue flying ... http://mail.flightgear.org/pipermail/flightgear-devel/2002-April/006392.html Congrats, David. You inspire us. :-) Thanks -- I've been thinking a lot about that posting, and about all the help and support I got from the list after that. Ownership scares me about as much now as flying did then. 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] PA-28-161 C-FBJO
David Megginson writes: I flew an Arrow-III up to Minneapolis and back this past weekend. Even with a CAS of 135 kts, I had a GS of about 80-88 kts the whole way up to Minneapolis at 6000 feet because of a cold front moving through. On the way back, I had a great tailwind and at 9000 feet I was at 130 kts CAS and 194 kts GS. With a top speed of 217 kts GS on a descent from 9000 to 7000 feet. Interesting. That's why people will pay for an extra few knots -- if you're flying into a 60kt headwind, a 120kt airplane is 1.5 times as fast as a 100kt airplane, for example. Oh, yeah, and you get your money back (with some interest) when you sell it in 10 or 20 years, while you might have to pay someone to toy the minivan away to the junk yard. I wouldn't choose a plane purely as an investment -- there's too much volatility for an average return of only about 7%/year over the past couple of decades (and flat over the past year or so) -- but given the markets since 2001, even if the plane just holds its current value it will be doing considerably better than my retirement investments. If you want to call it a fun 401K with wings, go for it. 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] terrasync
Cameron Moore writes: We would need to preserve the timestamp for the 302 code stuff to work. The biggest difference between rsync and HTTP is that rsync downloads diffs[1] while HTTP must download the entire file. This is a big plus for people with slow connections. I guess _my_ question in regard to rsync is how much would rsync actually help in our case. If a tile is changed -- say we fixed a runway or something -- would a diff accomplish anything since we have binary scenery files that are also gzipped? Would the rolling checksums that rsync does all end up being different, so we are always downloading the entire file anyway? If this is the case, then rsync's main advantage is worthless to us. [1] ftp://rsync.samba.org/pub/rsync/tech_report.ps My bet is that if we change a tile it will likely have to retransfer the whole thing, especially since we are compressing the files on disk. But to me, the main feature of rsync is that it does everything and I don't have to think about how it works or reimpliment it myself. :-) Regards, 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
Cameron Moore wrote: * [EMAIL PROTECTED] (David Megginson) [2002.12.05 09:45]: Christian Mayer writes: The missing functionality is the ability to figure out if the tile has changed IIRC. But that'n no problem - HTTP already supports that. IIRC it send's a status code of 302 if the reqested data didn't change... Exactly -- as long as the files are available unpacked in the standard directory structure via HTTP, everything should work just the same. We would need to preserve the timestamp for the 302 code stuff to work. that's no big deal I guess _my_ question in regard to rsync is how much would rsync actually help in our case. If a tile is changed -- say we fixed a runway or something -- would a diff accomplish anything since we have binary scenery files that are also gzipped? Would the rolling checksums that rsync does all end up being different, so we are always downloading the entire file anyway? If this is the case, then rsync's main advantage is worthless to us. I doubt that. As mentioned before: for a CD image where only a few files change (and those are hidden somewhere inbetween 640 MB) it's very well suited. But we've got a directory structure that gets mirrored on the client and there are only a few files in it that change - and those files probably change completely. 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
Tony Peden wrote: FTP is a horrible protocol. As firewall admin you've got the problem that FTP decides dynamically what port it uses for data transfer. So you have to open quite a few ports. In pasv mode (settable from the client) it uses only one ... For the SuSE update I din't find that option (probably didn't look long enough...) Dunno if that's the problem of the NAT part, but I can't reliably use FTP from my normal computer as packets get filterd at my router/firewall. This is already quite bad (e.g. for the SuSE auto update) so we should do it better. And we should help to get rid of FTP. 2.4 Linux kernels don't seem to have any trouble with it... My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. PS: FTP also transferes passwords in plaintext to make things even worse... And http doesn't? scp doesn't. And http can be exchanged by https. If there's a secure FTP my client probably can't handle it anyway. 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] PA-28-161 C-FBJO
legal ownership, but it is parked safely at the flying club waiting for me. I am quite impressed with the handling compared to the 172's I've flown. Here are some pics: http://www.megginson.com/private/C-FBJO/ For those of you that haven't been here for long, the same David Megginson made the following post back in April about his disappointing first training flight: ... I'd say that there's a 55% chance I won't continue flying ... http://mail.flightgear.org/pipermail/flightgear-devel/2002-April/006392.html Congrats, David. You inspire us. :-) ...and the Siren of Flight forever snatched poor David from the surly bonds of Earth... :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Christian Mayer wrote: If there's a secure FTP my client probably can't handle it anyway. sftp and sftpd are part of the OpenSSH package. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
--- Christian Mayer [EMAIL PROTECTED] wrote: Tony Peden wrote: FTP is a horrible protocol. As firewall admin you've got the problem that FTP decides dynamically what port it uses for data transfer. So you have to open quite a few ports. In pasv mode (settable from the client) it uses only one ... For the SuSE update I din't find that option (probably didn't look long enough...) Most clients have it. A client embedded in a gui may not (if that's what you've got) Dunno if that's the problem of the NAT part, but I can't reliably use FTP from my normal computer as packets get filterd at my router/firewall. This is already quite bad (e.g. for the SuSE auto update) so we should do it better. And we should help to get rid of FTP. 2.4 Linux kernels don't seem to have any trouble with it... My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. I think you want to use the newer ipchains ... I'll check and send you mine. PS: FTP also transferes passwords in plaintext to make things even worse... And http doesn't? scp doesn't. Yes, but that requires ssh, AFAIK. And http can be exchanged by https. True enough. If there's a secure FTP my client probably can't handle it anyway. The only one I know of isn't really ftp but sftp that comes with ssh. 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 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Error linking js_demo.exe
With the latest PLIB CVS joystick library, I get the following error when linking js_demo.exe (Cygwin/Win2k/gcc3.2): g++ -O2 -L/usr/local/lib -o js_demo.exe js_demo.o -lplibsl -lplibsm -lwinmm -lplibjs -lplibul -lm /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libplibjs.a(jsWindows.o)(.text+ 0x36 9):jsWindows.cxx: undefined reference to `_joyGetDevCapsA@12' /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libplibjs.a(jsWindows.o)(.text+ 0x6e c):jsWindows.cxx: undefined reference to `_joyGetPosEx@8' collect2: ld returned 1 exit status FG itself links fine so this is not a big issue. Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Fri, 6 Dec 2002 12:30:32 -0800 (PST), Tony Peden [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: --- Christian Mayer [EMAIL PROTECTED] wrote: Tony Peden wrote: My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. I think you want to use the newer ipchains ... I'll check and send you mine. ..uhmmm, in ipcop.org, we're actually moving from ipchains and the 2.2 kernels. But running ipchains with a 2.4 works fine if you accept loosing some of the neat stuff. ;-) PS: FTP also transferes passwords in plaintext to make things even worse... And http doesn't? scp doesn't. Yes, but that requires ssh, AFAIK. -- ..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
Re: [Flightgear-devel] terrasync
On Fri, 2002-12-06 at 13:12, Arnt Karlsen wrote: On Fri, 6 Dec 2002 12:30:32 -0800 (PST), Tony Peden [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: --- Christian Mayer [EMAIL PROTECTED] wrote: Tony Peden wrote: My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. I think you want to use the newer ipchains ... I'll check and send you mine. ..uhmmm, in ipcop.org, we're actually moving from ipchains and the 2.2 kernels. But running ipchains with a 2.4 works fine if you accept loosing some of the neat stuff. ;-) Yes, thank you. Since they change with every kernel, I always get them confused. PS: FTP also transferes passwords in plaintext to make things even worse... And http doesn't? scp doesn't. Yes, but that requires ssh, AFAIK. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: [Plib-devel] Compile errors with new ssg
Forwarded from PLIB-Devel list: -Original Message- From: Steve Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 6:12 PM To: [EMAIL PROTECTED] Subject: Re: [Plib-devel] Compile errors with new ssg Paul Deppe wrote: With the latest chnages to SSG, the following error occurs when compiling src/Objects/obj.cxx from FlightGear (Cygwin/Win2k/gcc3.2): if + -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/l ocal/include -O2 -MT obj.o -MD -MP -MF .deps/obj.Tpo \ -c -o obj.o `test -f 'obj.cxx' || echo './'`obj.cxx; \ then mv .deps/obj.Tpo .deps/obj.Po; \ else rm -f .deps/obj.Tpo; exit 1; \ fi obj.cxx: In member function `void LeafUserData::setup_triangle(int)': obj.cxx:625: cannot allocate an object of type `DummyBSphereEntity' obj.cxx:625: because the following virtual functions are abstract: /usr/include/plib/ssg.h:1175: virtual void ssgEntity::getStats(int*, int*, int*, int*) obj.cxx: In function `void gen_random_surface_objects(ssgLeaf*, ssgBranch*, Point3D*, const std::string)': obj.cxx:764: cannot allocate an object of type `DummyBSphereEntity' obj.cxx:764: since type `DummyBSphereEntity' has abstract virtual functions make[2]: *** [obj.o] Error 1 obj.cxx hasn't changed since 11/25/02 so this seems to be PLIB-related. It sounds like FGFS is creating a derived class of an ssgEntity that is neither an ssgBranch nor an ssgLeaf. If that's the case then I strongly disapprove. If that's the case then we should put this down to poor design in FGFS. CHange it to derive from either a leaf or a branch. Steve Baker - HomeEmail: [EMAIL PROTECTED]WorkEmail: [EMAIL PROTECTED] HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sf.nethttp://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ plib-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/plib-devel ___ 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
Re: [Flightgear-devel] Error linking js_demo.exe
Paul Deppe With the latest PLIB CVS joystick library, I get the following error when linking js_demo.exe (Cygwin/Win2k/gcc3.2): g++ -O2 -L/usr/local/lib -o js_demo.exe js_demo.o -lplibsl -lplibsm -lwinmm -lplibjs -lplibul -lm /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libplibjs.a(jsWindows.o)(.text+ 0x36 9):jsWindows.cxx: undefined reference to `_joyGetDevCapsA@12' /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libplibjs.a(jsWindows.o)(.text+ 0x6e c):jsWindows.cxx: undefined reference to `_joyGetPosEx@8' collect2: ld returned 1 exit status Try changing the xxx_LDADD lines in Makefile.am to js_demo_LDADD = -lplibjs -lplibul $(audio_LIBS) fgjs_LDADD = -lplibjs -lplibul $(audio_LIBS) Unlike unix link order matters with Windows Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On 06 Dec 2002 15:14:36 -0800, Tony Peden [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Fri, 2002-12-06 at 13:12, Arnt Karlsen wrote: On Fri, 6 Dec 2002 12:30:32 -0800 (PST), Tony Peden [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: --- Christian Mayer [EMAIL PROTECTED] wrote: Tony Peden wrote: My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. I think you want to use the newer ipchains ... I'll check and send you mine. ..uhmmm, in ipcop.org, we're actually moving from ipchains and the 2.2 kernels. But running ipchains with a 2.4 works fine if you accept loosing some of the neat stuff. ;-) Yes, thank you. Since they change with every kernel, I always get them confused. ..that tradition breaks with 2.5/2.6 (or is it 3.0?) ;-) -- ..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
