Re: [Flightgear-devel] AC_EXT_DAYLIGHT and AC_EXT_TIMEZONE
Maybe someone would like me to submit a patch for this? -- Ross On Tue, 2002-01-01 at 19:12, Ross Golder wrote: > Sorry for dragging this old problem up again, but it hasn't really been > solved. I know from experience that I should run 'aclocal -I .' when I > get this problem, but this isn't documented anywhere in the distribution > (or in CVS). Many users won't know to search the list archives. > > One post on the subject suggests that we can't just do '-I .' in the > autogen.sh and README.autoconf because of users who might have an > autoconf <= 2.13. Is that right? > > As I see it, the reason for doing '-I .' is so that autoconf picks up > the 'acsite.m4' file, but couldn't we just append the contents of > acsite.m4 to acinclude.m4? I've tried this locally, and it now 'works > for me' without the '-I .'. Can anyone see a downside to this? > > -- > Ross > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: Intro music on Windows
Blimey! What a wierd combination of effects. On Windows ME its nearly the same: just "start .\notepad" is different. C:\>ver Windows Millennium [Version 4.90.3000] C:\>start /m notepad -- notepad started minimized C:\>start .\notepad Cannot find file '.\notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\>start c:/Windows/notepad -- notepad started successfully C:\>start ./notepad Cannot find file './notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\>start ./notepad.exe -- notepad started successfully And also: C:\>start .\notepad.exe Cannot find file '.\notepad.exe' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. - Julian Norman Vine wrote: > > Julian Foad writes: > >> > >The "/m" switch specifies a minimised (iconised) window. > >Could Windows users check whether this is supported on various > >versions of Windows. It is on Windows ME. > > AFAIK 'start /m' is supported on all Win32 systems > > >The "cygpath -w" command converts the unix-like pathname to a > >Windows one which the Windows program will recognise. > >Something like this may be needed in the non-CygWin case. I'm > >not sure what the values of get_fg_root() and > >"/sim/startup/intro-music" will or should be. Can the SGPath > >class convert between native and unix-style pathnames? > > AFAIK get_fg_root() should always return a path that the > underlying system should understand, and WIN32 almost > understands . > > Note the following 'quirks' though > > Microsoft(R) Windows 98 >(C)Copyright Microsoft Corp 1981-1998. > > C:\WINDOWS>start /m notepad > -- notepad started minimized > > C:\WINDOWS>start .\notepad > -- notepad started successfuly > > C:\WINDOWS>start c:/Windows/notepad > -- notepad starts successfuly > > C:\WINDOWS>start ./notepad > Cannot find file './notepad' (or one of its components). Check > to ensure the path and filename are correct and that all required > libraries are available. > > C:\WINDOWS>start ./notepad.exe > -- notepad started successfuly > > to be sure of success when launching a program with start on WIN32 > use the FULL filename to include the extension ! > > Cheers > > Norman > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] Problem compiling recent Simgear CVS
OK: a CygWin update followed by "mv acsite.m4 aclocal.m4" fixed it for me. Details
below.
Norman Vine wrote:
>
> Julian Foad writes:
> >
> >Now I've got another problem with it. I don't seem to need
> >the AC_PREREQ(2.13) any more (it doesn't make any difference
> >to the following output), but I get "CXX =" and "CC ="
> >followed by failure further down. Although it says "checking
> >whether make sets ${MAKE}... (cached) yes", there is no
> >config.cache file before or after I try this.
> >
> >
> >$ ./autogen.sh
> >Host info: CYGWIN_ME-4.90 i686
> > automake: 1.4 (14)
> >
> >Running aclocal
>
> This should be
>
> aclocal -I .
>
The autogen.sh adds "-I ." only for Irix. That souns a bit suspicious because I used
to have to use it in CygWin, so I tried it just now, but it didn't make any difference
to my present problem. I guess it's needed for some versions of the autotools but not
others.
Then I updated my CygWin autotools to the latest, because although my older versions
had been working OK I thought I might have an inconsistent set of different packages.
This led to different errors, and since the CygWin installer doesn't let me return to
earlier versions even though I still have the package files locally, I had to continue.
Host info: CYGWIN_ME-4.90 i686
automake: 1.4-p5 (14)
Running aclocal
Running autoheader
./aclocal.m4:254: /usr/bin/m4: Warning: Excess arguments to built-in `define' ignored
/usr/autotool/stable/bin/autoheader: Symbol `GZCAT' is not covered by
/usr/autotool/stable/share/autoconf/acconfig.h ./acconfig.h
/usr/autotool/stable/bin/autoheader: Symbol `ZCAT' is not covered by
/usr/autotool/stable/share/autoconf/acconfig.h ./acconfig.h
Running automake --add-missing
automake: Makefile.am: installing `./INSTALL'; error while making link: File exists
Running autoconf
./aclocal.m4:254: /usr/bin/m4: Warning: Excess arguments to built-in `define' ignored
configure.in:32: AC_PROG_CPP was called before AC_PROG_CC
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_CC
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_MSG
...
Eventually I remembered that Ross Golder had found that "mv acsite.m4 acinclude.m4"
worked for him. I already had an acinclude.m4 which was identical to my acsite.m4, so
the only effect of this command was to delete acsite.m4. But it worked! I wish I
understood this magic.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Patch: Intro music on Windows
Julian Foad writes: >> >The "/m" switch specifies a minimised (iconised) window. >Could Windows users check whether this is supported on various >versions of Windows. It is on Windows ME. AFAIK 'start /m' is supported on all Win32 systems >The "cygpath -w" command converts the unix-like pathname to a >Windows one which the Windows program will recognise. >Something like this may be needed in the non-CygWin case. I'm >not sure what the values of get_fg_root() and >"/sim/startup/intro-music" will or should be. Can the SGPath >class convert between native and unix-style pathnames? AFAIK get_fg_root() should always return a path that the underlying system should understand, and WIN32 almost understands . Note the following 'quirks' though Microsoft(R) Windows 98 (C)Copyright Microsoft Corp 1981-1998. C:\WINDOWS>start /m notepad -- notepad started minimized C:\WINDOWS>start .\notepad -- notepad started successfuly C:\WINDOWS>start c:/Windows/notepad -- notepad starts successfuly C:\WINDOWS>start ./notepad Cannot find file './notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\WINDOWS>start ./notepad.exe -- notepad started successfuly to be sure of success when launching a program with start on WIN32 use the FULL filename to include the extension ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling recent Simgear CVS
Norman Vine wrote: > > Michael Basler writes: > >Julian Foad write: > > > >> Until this is fixed properly, you can fix this by adding the line: > >> > >> AC_PREREQ(2.13) > >> > >> at the beginning of configure.in, just after the "dnl ..." lines > >> which are comments. At least, this works for me. > > > >One million thanks, Julian, this fixed the case for me. Same goes for > >FlightGear, as I detected a few minutes later. > > > >Could someone "responsible" (Curt, Dave...) fix this in the > >CVS? Thanks a lot. > > The problem is that the GNU autotools had a non-backwards > compatable change and we might have to live with hand tweaking > the configure scripts for a while untill all systems have changed > over to the newer release They did have a major change, but adding AC_PREREQ(2.13) is a way of making the files compatible with the new CygWin autotools (the auto-detecting ones that explicitely look for this), while still remaining compatible with the old ones. I use the old versions of the tools and they work fine with or without that line. I hope that's right because I recently asked Curt to add that line in both SimGear/configure.in and FlightGear/configure.in. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Patch: Intro music on Windows
This patch plays the intro music on CygWin (I've tested) but I don't know whether it
will work on non-CygWin Windows - see note on "cygpath -w" below.
The "start" command launches any program that is associated with the ".mp3" file name
extension. Typically this might be MS Windows Media Player. If no program is
associated, an error message will be issued in the sub-shell but this will not be seen
nor detected by FlightGear, so FG will just continue without music.
The "/m" switch specifies a minimised (iconised) window. Could Windows users check
whether this is supported on various versions of Windows. It is on Windows ME.
The "cygpath -w" command converts the unix-like pathname to a Windows one which the
Windows program will recognise. Something like this may be needed in the non-CygWin
case. I'm not sure what the values of get_fg_root() and "/sim/startup/intro-music"
will or should be. Can the SGPath class convert between native and unix-style
pathnames?
This whole attempt is not very satisfactory. In my system, though I had at least one
program capable of playing ".mp3" files, none was registered as associated with that
extension, so I had to set it manually. The Media Player remains open after it has
finished playing. If it is already open, the "minimise" request has no effect. Is
there a better way? Yes - use a player built in to one of our portability libraries -
SimGear or PLIB. But there isn't an MP3 player there yet.
Shall I send this to Curt as a temporary fix? (I know many of you aren't interested
in intro music, but I say if it's there on one platform let's have it on all.)
- Julian
[Patch: in main.cxx: fgIdleFunction()]
#ifdef ENABLE_AUDIO_SUPPORT
// Start the intro music
-#if !defined(WIN32)
if ( fgGetBool("/sim/startup/intro-music") ) {
SGPath mp3file( globals->get_fg_root() );
mp3file.append( "Sounds/intro.mp3" );
SG_LOG( SG_GENERAL, SG_INFO,
"Starting intro music: " << mp3file.str() );
+#if defined(__CYGWIN__)
+ string command = "start /m `cygpath -w " + mp3file.str() + "`";
+#elif defined(WIN32)
+ string command = "start /m " + mp3file.str();
+#else
string command = "mpg123 " + mp3file.str() + "> /dev/null 2>&1";
+#endif
system ( command.c_str() );
}
-#endif // !WIN32
#endif
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Floating Point Exceptions
On Sun, 2002-01-20 at 10:47, Norman Vine wrote: > Tony Peden writes: > > > >Well, I've spent quite a few hours on this and AFAICT, the FPU > >is being set up correctly, it's just not generating the exception > >for a floating point divide by zero (or any other floating point error > >I could induce). Integer divide by zero works just fine. > > Tony > > Try adding this in addition to your other flags > > #ifdef linux > /* Linux used to deliver SIGFPE by default, but no longer. Sigh. */ > __setfpucw(0x1372); > #endif Do you know what header and lib this is in? It's in fpu_control.h in the glibc (2.2) source, but not in the fpu_control.h installed on the system. Declaring it extern just generates complaints from the linker. > > Cheers > > Norman > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Floating Point Exceptions
Tony Peden writes: > >Well, I've spent quite a few hours on this and AFAICT, the FPU >is being set up correctly, it's just not generating the exception >for a floating point divide by zero (or any other floating point error >I could induce). Integer divide by zero works just fine. Tony Try adding this in addition to your other flags #ifdef linux /* Linux used to deliver SIGFPE by default, but no longer. Sigh. */ __setfpucw(0x1372); #endif Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: AW: [Flightgear-devel] Problem compiling recent Simgear CVS
Julian Foad writes:
>
>Now I've got another problem with it. I don't seem to need
>the AC_PREREQ(2.13) any more (it doesn't make any difference
>to the following output), but I get "CXX =" and "CC ="
>followed by failure further down. Although it says "checking
>whether make sets ${MAKE}... (cached) yes", there is no
>config.cache file before or after I try this.
>
>
>$ ./autogen.sh
>Host info: CYGWIN_ME-4.90 i686
> automake: 1.4 (14)
>
>Running aclocal
This should be
aclocal -I .
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem compiling recent Simgear CVS
Michael Basler writes: >Julian Foad write: > >> Until this is fixed properly, you can fix this by adding the line: >> >> AC_PREREQ(2.13) >> >> at the beginning of configure.in, just after the "dnl ..." lines >> which are comments. At least, this works for me. > >One million thanks, Julian, this fixed the case for me. Same goes for >FlightGear, as I detected a few minutes later. > >Could someone "responsible" (Curt, Dave...) fix this in the >CVS? Thanks a lot. The problem is that the GNU autotools had a non-backwards compatable change and we might have to live with hand tweaking the configure scripts for a while untill all systems have changed over to the newer release Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] properties problem
By "false" you mean they are null, I assume. Well, "latitude" and "longitude" are
created a few lines further up by:
// Any time after globals is created we are ready to use the
// property system
static const SGPropertyNode *longitude
= fgGetNode("/position/longitude-deg", true);
static const SGPropertyNode *latitude
= fgGetNode("/position/latitude-deg", true);
So these must be failing. There should probably be a check for null pointers there.
- Julian
Erik Hofman wrote:
>
> Julian Foad wrote:
>
> > Erik Hofman wrote:
> >
> >>The latest FlightGear from CVS gives me a core after startup.
> >>I traced it back to SimGear/simgear/misc/props.hxx line 730:
> >>
> >>Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
> >>(default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
> >>const:730 +0x10,0x103b2110]
> >> 730 bool getAttribute (Attribute attr) const { return ((_attr & attr)
> >>!= 0); }
> >>
> >>I have no idea why this happens.
> >>Does anybody else have any idea?
> >>
> >
> > I think you need to look higher up in the call stack: perhaps the object pointer
>on which this method is called was invalid.
>
> You are right, I forgot to mention:
>
> I tracked the probelm down to FlightGear/src/Maim/main.cxx
> SGTime *t = new SGTime( longitude->getDoubleValue()
>* SGD_DEGREES_TO_RADIANS,
> latitude->getDoubleValue()
>* SGD_DEGREES_TO_RADIANS,
> zone.str() );
>
> Tests show that both longitude and latitude are false ...
> Hope this helps some more.
>
> Erik
> I'm lost at this one :(
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Floating Point Exceptions
On Sat, 2002-01-19 at 07:20, Tony Peden wrote: > I've been trying to reproduce the reported problem in FGInitialCondition > and would like to have floating point exceptions enabled to do that. > The trouble is that I can't seem to get it to work like I expect. > On linux, if I either the method in src/Main/main.cxx: > > fpu_control_t fpe_flags; > _FPU_GETCW(fpe_flags); > fpe_flags &= ~_FPU_MASK_IM; // invalid operation > fpe_flags &= ~_FPU_MASK_DM; // denormalized operand > fpe_flags &= ~_FPU_MASK_ZM; // zero-divide > fpe_flags &= ~_FPU_MASK_OM; // overflow > fpe_flags &= ~_FPU_MASK_UM; // underflow > fpe_flags &= ~_FPU_MASK_PM; // precision (inexact result) > _FPU_SETCW(fpe_flags); > > or that defined in fenv.h: > feenableexcepts(FE_ALL_EXCEPT) > > I'll get an exception for > float a= 3/0 > but *not* for > float a=3/0.0 > even though both div by zero and overflow are enabled, AFAICT. > > Does anyone understand what's happening here? Well, I've spent quite a few hours on this and AFAICT, the FPU is being set up correctly, it's just not generating the exception for a floating point divide by zero (or any other floating point error I could induce). Integer divide by zero works just fine. This has implications for FG as well, as I've used FG's code in my experiments. I don't know what it is that needs to be done but until we figure it out I don't think the code in FG is really doing much of anything as most of the math is floating point as far as I know. Of course, it's not hurting anything either ... > > > -- > Tony Peden > [EMAIL PROTECTED] > We all know Linux is great ... it does infinite loops in 5 seconds. > -- attributed to Linus Torvalds > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim and MSVC
I committed a fix to the FGInitialCondition problem this morning. If the MSVC folks could give it a shot without your fixes (either from JSBSim CVS or wait for FG CVS to be updated) I'd really appreciate it. The problem did exist on linux, as well, but somehow never surfaced. It was only after digging pretty deep that I found it. -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] Problem compiling recent Simgear CVS
Now I've got another problem with it. I don't seem to need the AC_PREREQ(2.13) any
more (it doesn't make any difference to the following output), but I get "CXX =" and
"CC =" followed by failure further down. Although it says "checking whether make sets
${MAKE}... (cached) yes", there is no config.cache file before or after I try this.
The autogen.sh here is identical to the one in FlightGear/ but FlightGear configure
works fine.
I'm using automake 1.4 and autoconf 2.52 in CygWin.
Any ideas anyone?
- Julian
$ ./autogen.sh
Host info: CYGWIN_ME-4.90 i686
automake: 1.4 (14)
Running aclocal
Running autoheader
Running automake --add-missing
Running autoconf
==
Now you are ready to run './configure'
==
$ ./configure
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
CXX =
CC =
checking whether make sets ${MAKE}... (cached) yes
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
configure: error: cannot run /bin/sh ./config.sub
$
Michael Basler wrote:
>
> > -Ursprungliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]Im Auftrag von Julian Foad
>
> > Until this is fixed properly, you can fix this by adding the line:
> >
> > AC_PREREQ(2.13)
> >
> > at the beginning of configure.in, just after the "dnl ..." lines
> > which are comments. At least, this works for me.
>
> One million thanks, Julian, this fixed the case for me. Same goes for
> FlightGear, as I detected a few minutes later.
>
> Could someone "responsible" (Curt, Dave...) fix this in the CVS? Thanks a
> lot.
>
> Regards, Michael
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Re: BUG: option --tile-radius missing
> I asked for --tile-radius, because I don't get enough tiles if I > fly at good visibility (--fog-disable or hitting 'Z' a few times). >> only schedules tiles for loading when you cross a tile boundary Is this out of line ... using --fdm=magic ... rise to say 15,000 feet, clear fog and clouds, no panel, HUD up ... select 090 degrees ... hit max throttle ... First congratulations to the tile manager to get it organised under such chaoit conditions ... flying directly east at some 3980 somethings ... but it does it very well ... It throws out frequent reports that is is freeing a perfectly good tile, which one would really expect in such a manouvre, but generally gets on with the tough job ... landscaping USA going E too fast for reality to set in ... But the 'scenery manager - tile manager' has a 'responsibility' to paint out to the visible horizon, regardless of whether a 'tile' for that scenerenry has been loaded - ie is within sight ... or anything. Or 'someone' should be responsible for completing the earths shape if the currently loaded tiles fail to fill in this 'gap' ... When tm completes a paint of the currently loaded tiles it must paint in gray (with red cross lines say *not valid scenery* if necessary) out to the earth's visible horizon, if any part of that 'visible line' is above all currently loaded scenery ... given ac height, etc ... In the above mad 'flight' there are places where the tile manager only loads say the right half of the 'forward' scene, because the ac is slightly within this tile, but does not load the 'left' half of that 'forward' scene piece, leading to a rather 'weird' = un-real external view ... could send you some interesting 'snapshots'. In this case, even with no tile search for the left, it should be painted foward at least as far as the tile to the right of it ... but again it should continue this 'gray out' until the sky dome intercedes ... I could tell myself the view of the world was through a 9600 baud serial link and thus could never quite 'complete' during any specific update. Thus it was not weird, but rather normal for our warp speed external view monitors of earth ... need tech update. :-) I wish I understood more of the tile management - scenery painting code so I could make this more than - should it not be like this? On a good clear day I can 'see' the horizon from 10, 20, 30, ++ (th) feet up ... It looks quite 'crisp', if indistinct ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base package CVS: "read lock failed"
Thanks, John - that fixes it. I suppose CVS didn't delete it because I had made modifications in it. I'd expect it to say so, though! - Julian John Check wrote: > > just did cvs up -dP and no problems. Try deleting your c172/Instruments > directory, it's no longer relevant. > > TTYL > J > > > > On Wednesday 16 January 2002 04:28 pm, you wrote: > > > > Does this indicate a problem on the base package CVS server? > > > > > > > > ... > > > > cvs server: Diffing Aircraft/X15/Panels > > > > cvs server: Diffing Aircraft/X15/Panels/Textures > > > > cvs server: Diffing Aircraft/c172 > > > > cvs server: Diffing Aircraft/c172/Instruments > > > > cvs server: failed to create lock directory in repository > > > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments': No > > > > such file or directory cvs server: failed to obtain dir lock in > > > > repository > > > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments' cvs > > > > [server aborted]: read lock failed - giving up > > > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] Problem compiling recent Simgear CVS
> -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]Im Auftrag von Julian Foad > Until this is fixed properly, you can fix this by adding the line: > > AC_PREREQ(2.13) > > at the beginning of configure.in, just after the "dnl ..." lines > which are comments. At least, this works for me. One million thanks, Julian, this fixed the case for me. Same goes for FlightGear, as I detected a few minutes later. Could someone "responsible" (Curt, Dave...) fix this in the CVS? Thanks a lot. 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] properties problem
Julian Foad wrote:
> Erik Hofman wrote:
>
>>The latest FlightGear from CVS gives me a core after startup.
>>I traced it back to SimGear/simgear/misc/props.hxx line 730:
>>
>>Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
>>(default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
>>const:730 +0x10,0x103b2110]
>> 730 bool getAttribute (Attribute attr) const { return ((_attr & attr)
>>!= 0); }
>>
>>I have no idea why this happens.
>>Does anybody else have any idea?
>>
>
> I think you need to look higher up in the call stack: perhaps the object pointer on
>which this method is called was invalid.
You are right, I forgot to mention:
I tracked the probelm down to FlightGear/src/Maim/main.cxx
SGTime *t = new SGTime( longitude->getDoubleValue()
* SGD_DEGREES_TO_RADIANS,
latitude->getDoubleValue()
* SGD_DEGREES_TO_RADIANS,
zone.str() );
Tests show that both longitude and latitude are false ...
Hope this helps some more.
Erik
I'm lost at this one :(
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem compiling recent Simgear CVS
Julian Foad writes: > >Until this is fixed properly, you can fix this by adding the line: > >AC_PREREQ(2.13) > >at the beginning of configure.in, just after the "dnl ..." >lines which are comments. At least, this works for me. > Just running make again seems to work also Don't ask me why Norman >Michael Basler wrote: >> >> Hi, >> >> when I tried to build CVS Simgear today, I got with autogen.sh: >> >> -- >> Michael Basler@MICHAEL /usr/local/source/simgear >> $ ./autogen.sh >> Host info: CYGWIN_NT-5.1 i686 >> automake: 1.5 (15) >> >> Running aclocal >> Running autoheader >> autoheader: simgear/simgear_config.h.in is unchanged >> Running automake --add-missing >> simgear/bucket/Makefile.am: INCLUDES must be set with `=' >before using `+=' >> simgear/debug/Makefile.am: INCLUDES must be set with `=' >before using `+=' >> simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' >before using >> `+=' >> >> simgear/xml/Makefile.am: INCLUDES must be set with `=' >before using `+=' >> Running autoconf >> configure.in:18: error: possibly undefined macro: AC_SG_SET_COMPILER >> >> == >... > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base package CVS: "read lock failed"
On Sunday 20 January 2002 10:40 am, you wrote: > Still happening just the same. Is it my fault? > > - Julian > Maybe I just did an anonymous checkout and it seems to be working. What are you doing exactly, a checkout or an update? Hmm... just did cvs up -dP and no problems. Try deleting your c172/Instruments directory, it's no longer relevant. TTYL J > John Check wrote: > > On Wednesday 16 January 2002 04:28 pm, you wrote: > > > Does this indicate a problem on the base package CVS server? > > > > > > ... > > > cvs server: Diffing Aircraft/X15/Panels > > > cvs server: Diffing Aircraft/X15/Panels/Textures > > > cvs server: Diffing Aircraft/c172 > > > cvs server: Diffing Aircraft/c172/Instruments > > > cvs server: failed to create lock directory in repository > > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments': No > > > such file or directory cvs server: failed to obtain dir lock in > > > repository > > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments' cvs > > > [server aborted]: read lock failed - giving up > > > > > > > > > - Julian > > > > OOps, somebody added directories.. will fix shortly > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling recent Simgear CVS
Until this is fixed properly, you can fix this by adding the line: AC_PREREQ(2.13) at the beginning of configure.in, just after the "dnl ..." lines which are comments. At least, this works for me. - Julian Michael Basler wrote: > > Hi, > > when I tried to build CVS Simgear today, I got with autogen.sh: > > -- > Michael Basler@MICHAEL /usr/local/source/simgear > $ ./autogen.sh > Host info: CYGWIN_NT-5.1 i686 > automake: 1.5 (15) > > Running aclocal > Running autoheader > autoheader: simgear/simgear_config.h.in is unchanged > Running automake --add-missing > simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' > simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' > simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using > `+=' > > simgear/xml/Makefile.am: INCLUDES must be set with `=' before using `+=' > Running autoconf > configure.in:18: error: possibly undefined macro: AC_SG_SET_COMPILER > > == ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Auto-generated files in CVS
This has been discussed before and I don't recall any reason why these auto-generated files should be in CVS. If this is the case please could someone remove them. SimGear: aclocal.m4 simgear/simgear_config.h.in FlightGear: aclocal.m4 src/Include/config.h.in - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base package CVS: "read lock failed"
Still happening just the same. Is it my fault? - Julian John Check wrote: > > On Wednesday 16 January 2002 04:28 pm, you wrote: > > Does this indicate a problem on the base package CVS server? > > > > ... > > cvs server: Diffing Aircraft/X15/Panels > > cvs server: Diffing Aircraft/X15/Panels/Textures > > cvs server: Diffing Aircraft/c172 > > cvs server: Diffing Aircraft/c172/Instruments > > cvs server: failed to create lock directory in repository > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments': No such > > file or directory cvs server: failed to obtain dir lock in repository > > `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments' cvs [server > > aborted]: read lock failed - giving up > > > > > > - Julian > > > > OOps, somebody added directories.. will fix shortly > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] properties problem
Erik Hofman wrote:
>
> The latest FlightGear from CVS gives me a core after startup.
> I traced it back to SimGear/simgear/misc/props.hxx line 730:
>
> Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
> (default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
> const:730 +0x10,0x103b2110]
> 730 bool getAttribute (Attribute attr) const { return ((_attr & attr)
> != 0); }
>
> I have no idea why this happens.
> Does anybody else have any idea?
I think you need to look higher up in the call stack: perhaps the object pointer on
which this method is called was invalid.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] properties problem
Hi,
The latest FlightGear from CVS gives me a core after startup.
I traced it back to SimGear/simgear/misc/props.hxx line 730:
Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
(default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
const:730 +0x10,0x103b2110]
730 bool getAttribute (Attribute attr) const { return ((_attr & attr)
!= 0); }
I have no idea why this happens.
Does anybody else have any idea?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changes in SimGear
Erik Hofman wrote: > > Christian Mayer wrote: > > > > Anyway, could all > > > > #include > > > > lines be changed back to > > > > #ifdef HAVE_ZLIB > > # include > > #else > > # include > > #endif > > > > w/o causing any trouble? This would help me. I wouldn't need any other > > change as the directories are still there. > > You have to realize that metakit and zlib aren't compiled in SimGear > anymore. Adding thise lines may also add some confusion. You are right about the standard make process. But as MSVC doesn't have zlib (I didn't have problems with metakit but that should be theoretically the same problem) I have to compile it with SimGear. I wouldn't care if it's changed to #ifndef HAVE_NO_ZLIB but just a plain doesn't work for me (w/o much hazle). CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changes in SimGear
Christian Mayer wrote: > Anyway, could all > > #include > > lines be changed back to > > #ifdef HAVE_ZLIB > # include > #else > # include > #endif > > w/o causing any trouble? This would help me. I wouldn't need any other > change as the directories are still there. You have to realize that metakit and zlib aren't compiled in SimGear anymore. Adding thise lines may also add some confusion. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changes in SimGear
"Curtis L. Olson" wrote: > > Christian Mayer writes: > > Hi, > > > > is there a reason why SimGear/misc/zfstram.hxx was changed from > > > > #ifdef HAVE_ZLIB > > # include > > #else > > # include > > #endif > > > > to > > > > #include > > > It was a slight phylisophical shift. Although zlib and metakit aren't > standard on all systems, they are standard on many systems, and there > were various problems trying to build them inside of the simgear make > system. Well, standard on most *nix systems. But not Windos (but probably not Cygwin) Anyway, could all #include lines be changed back to #ifdef HAVE_ZLIB # include #else # include #endif w/o causing any trouble? This would help me. I wouldn't need any other change as the directories are still there. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SubGear Peek
Norman Vine wrote: > just a teaser image for now > http://www.vso.cape.com/~nhv > > FWIW - good data is hard to get Cool stuff. I've been thinking to use this data (except for submarine simulation) for coastlines in FlightGear (different textures for waterhights of less than (lets say) 60 feet. BTW. There *is* a 3 arcsec database for the complete ocean, but I don't know where that was :( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem compiling recent Simgear CVS
Hi, when I tried to build CVS Simgear today, I got with autogen.sh: -- Michael Basler@MICHAEL /usr/local/source/simgear $ ./autogen.sh Host info: CYGWIN_NT-5.1 i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/xml/Makefile.am: INCLUDES must be set with `=' before using `+=' Running autoconf configure.in:18: error: possibly undefined macro: AC_SG_SET_COMPILER == Now you are ready to run './configure' == Configure does not work. I did not build simgear for a while - do I miss something? This is against recent PLIB CVS under Win XP + Cygwin. 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] Re: BUG: option --tile-radius missing
* Curtis L. Olson -- Saturday 19 January 2002 23:35: > Melchior FRANZ writes: > Perhaps it could be tied, but not directly, the far clip plan has to > at least include the sky dome, sun, moon, stars, planets, clouds, > etc. even when the visibility is rather low. OK, yes. I meant that the far clip plane should never be nearer than visibility. It's then up to the user to set the visibility to a value that his machine/graphic card can still handle. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
