When I run fgfs to replay a data file which I saved, I got the following error:

Running Main Loop
======= ==== ====
Updating time
  Current Unix calendar time = 1098302223  warp = 28320
  Current GMT = 10/20/2004 19:57:3
  Current Unix calendar time = 1098302223  warp = 28320
  Current GMT = 10/20/2004 19:57:3
  Current Julian Date = 2.4533e+06
  COURSE: GMT = 9/20/104 19:57:03
  March 21 noon (GMT) = 1079870400
  Time since 3/21/104 GMT = 213.331
  days = 213  hours = 19.9508  lon = 0  lst = 22.1508
  COURSE: GMT = 9/20/104 19:57:03
  March 21 noon (GMT) = 1079870400
  Time since 3/21/104 GMT = 213.331
  days = 213  hours = 19.9508  lon = 122.357  lst = 13.9937
  Current lon=0.00 Sidereal Time = 21.9033
  gst => 141.925
  Current LOCAL Sidereal Time = 13.7461 (13.7679) (diff = -0.247568)
Elapsed time interval is = 4226000, previous remainder is = 6073
--> Frame rate is = 3
Model iterations needed = 507, new remainder = 7073
interpolate(): lookup error, x to small = -5.16431
interpolate(): lookup error, x to small = -2.16431
Updating adjusted fog parameters.
Segmentation fault (core dumped)

Does any one know why this happened and how to debug it?

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, October 20, 2004 6:55 PM
To: [EMAIL PROTECTED]
Subject: Flightgear-devel Digest, Vol 18, Issue 53


Send Flightgear-devel mailing list submissions to
        [EMAIL PROTECTED]

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.flightgear.org/mailman/listinfo/flightgear-devel
or, via email, send a message with subject or body 'help' to
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Flightgear-devel digest..."


Today's Topics:

   1. Re: TaxiDraw-0.2.2 released (David Luff)
   2. Linker problems with CVS version (Luca Masera)
   3. RE: Submodels (Vivian Meazza)
   4. kr_87 linker problems solved: was an error in
      "instrument_mgr.cxx" (Luca Masera)
   5. Re: TaxiDraw-0.2.2 released (David Luff)
   6. Re: kr_87 linker problems solved: was an error in
      "instrument_mgr.cxx" (Frederic Bouvier)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Oct 2004 10:43:57 +0100
From: "David Luff" <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] TaxiDraw-0.2.2 released
To: "FlightGear developers discussions"
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"



On 10/19/04 at 11:57 AM Chris Metzler wrote:
>Finally, I'm wondering how you're going to handle conflicts between future
>X-Plane data releases, and changes that people have sent to you.  For
>example, suppose an FG user sends some changes to an airport to you; and
>suppose some X-Plane user sends some changes to the same airport to Robin
>Peel (or the DAFIF changes for that airport).  The next X-Plane dataset
>contains the changes that Robin Peel received, which are different from
>the ones you have.  How would that get resolved?  Go with theirs?  Go with
>ours?  Contact the person who sent you changes to review the situation and
>update?
>

Well, in a way this is no different from before, in that several folk could
have separately sent Robin submissions for the same airport during the same
data cycle.  There's really no way round this - at least the airport in
question should end up with some taxiways at the end of the day.  I shall
endeavour to get them sent on to him as soon as possible once he's back in
communication in order to minimise the chance of this.  FWIW, don't bother
doing KOXR, KGYY, KDPA or KCPU or you'll be duplicating my work.

At the end of the day, I figured that maintaining some sort of diff to the
master database was the only way that TaxiDraw users would get to see their
stuff in FlightGear in the near future, especially given that regenerating
the scenery oneself is somewhat non-trivial, and requires some extremely
large downloads.  I guess we'll see how it works out in time.

Cheers - Dave  



This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.




------------------------------

Message: 2
Date: Wed, 20 Oct 2004 11:59:23 +0200
From: "Luca Masera" <[EMAIL PROTECTED]>
Subject: [Flightgear-devel] Linker problems with CVS version
To: "flightgear-devel" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1

Hi everyone,

I've downloaded the CVS patches to update my version of FlightGear.
They compile but I've a lot of problems from the linker. They are:

kr_87.obj : error LNK2005: "public: __thiscall FGKR_87::FGKR_87(class SGPropertyNode 
*)" (??0FGKR_87@@[EMAIL PROTECTED]@@@Z) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: virtual __thiscall FGKR_87::~FGKR_87(void)" 
(??1FGKR_87@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::init(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::unbind(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: int __thiscall FGKR_87::get_stby_freq(void)const " 
([EMAIL PROTECTED]@@QBEHXZ) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: void __thiscall FGKR_87::search(void)" ([EMAIL 
PROTECTED]@@QAEXXZ) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::bind(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj
kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::update(double)" 
([EMAIL PROTECTED]@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj
kr_87.obj : warning LNK4006: "public: __thiscall FGKR_87::FGKR_87(class SGPropertyNode 
*)" (??0FGKR_87@@[EMAIL PROTECTED]@@@Z) already defined in instrument_mgr.obj; second 
definition ignored
kr_87.obj : warning LNK4006: "public: virtual __thiscall FGKR_87::~FGKR_87(void)" 
(??1FGKR_87@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj; second 
definition ignored
kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::init(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition 
ignored
kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::unbind(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition 
ignored
kr_87.obj : warning LNK4006: "public: int __thiscall FGKR_87::get_stby_freq(void)const 
" ([EMAIL PROTECTED]@@QBEHXZ) already defined in instrument_mgr.obj; second definition 
ignored
kr_87.obj : warning LNK4006: "public: void __thiscall FGKR_87::search(void)" ([EMAIL 
PROTECTED]@@QAEXXZ) already defined in instrument_mgr.obj; second definition ignored
kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::bind(void)" 
([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition 
ignored
kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::update(double)" 
([EMAIL PROTECTED]@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj; second 
definition ignored
   Creating library .\Release/FlightGear.lib and object .\Release/FlightGear.exp
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_anzg(void)" 
(?get_anzg@@YAMXZ) referenced in function "class instr_item * __cdecl readCard(class 
SGPropertyNode const *)" (?readCard@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_Ax(void)" 
(?get_Ax@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud_ladr.obj : error LNK2001: unresolved external symbol "float __cdecl get_Ax(void)" 
(?get_Ax@@YAMXZ)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux18(void)" 
(?get_aux18@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux17(void)" 
(?get_aux17@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux16(void)" 
(?get_aux16@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux15(void)" 
(?get_aux15@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux14(void)" 
(?get_aux14@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux13(void)" 
(?get_aux13@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux12(void)" 
(?get_aux12@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux11(void)" 
(?get_aux11@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux10(void)" 
(?get_aux10@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux9(void)" 
(?get_aux9@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux8(void)" 
(?get_aux8@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux7(void)" 
(?get_aux7@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux6(void)" 
(?get_aux6@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux5(void)" 
(?get_aux5@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux4(void)" 
(?get_aux4@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux3(void)" 
(?get_aux3@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux2(void)" 
(?get_aux2@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud_ladr.obj : error LNK2001: unresolved external symbol "float __cdecl 
get_aux2(void)" (?get_aux2@@YAMXZ)
hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux1(void)" 
(?get_aux1@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class 
SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z)
hud_ladr.obj : error LNK2001: unresolved external symbol "float __cdecl 
get_aux1(void)" (?get_aux1@@YAMXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "float __cdecl get_Az(void)" 
(?get_Az@@YAMXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "float __cdecl get_Ay(void)" 
(?get_Ay@@YAMXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "float __cdecl get_Vz(void)" 
(?get_Vz@@YAMXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "float __cdecl get_Vy(void)" 
(?get_Vy@@YAMXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "float __cdecl get_Vx(void)" 
(?get_Vx@@YAMXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "int __cdecl get_iaux6(void)" 
(?get_iaux6@@YAHXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "int __cdecl get_iaux5(void)" 
(?get_iaux5@@YAHXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "int __cdecl get_iaux4(void)" 
(?get_iaux4@@YAHXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "int __cdecl get_iaux3(void)" 
(?get_iaux3@@YAHXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
hud_ladr.obj : error LNK2019: unresolved external symbol "int __cdecl get_iaux2(void)" 
(?get_iaux2@@YAHXZ) referenced in function "public: virtual void __thiscall 
HudLadder::draw(void)" ([EMAIL PROTECTED]@@UAEXXZ)
.\Release/FlightGear.exe : fatal error LNK1120: 30 unresolved externals

I work with Visual Studio .NET. 
In the project I modified I've created a new folder and added to it the files into SP 
subdirectory 
of FDM. I've also moved from the Cockpit folder to the Instrumentation folded the 
files ks_87.hxx 
and hr_87.cxx. 

Why I've this errors? I've watched the code and the include are correclty updated. 

Thanks, Luca

PS: I've tried to remove the #ifdef ENABLE_SP_FMDS and #endif into the file 
cockpit.cxx, but this 
doesn't solved the problem. However, I don't know the cause of kr_87 redifinitions. 
They are 
defined only into this file. I've tried to rebuild all, but this doesn't changed the 
output errors.



____________________________________________________________
Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. 
Abbonati subito su http://www.libero.it 





------------------------------

Message: 3
Date: Wed, 20 Oct 2004 11:03:53 +0100
From: "Vivian Meazza" <[EMAIL PROTECTED]>
Subject: RE: [Flightgear-devel] Submodels
To: "'FlightGear developers discussions'"
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;       charset="us-ascii"



Roy Vegard Ovesen
> Sent: 20 October 2004 00:32
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Submodels
> 
> On Tuesday 19 October 2004 19:42, Vivian Meazza wrote:
> > It's not obviously a path problem. My preferences.xml file was updated
> at
> > 15:22 yesterday, and has the right paths to the new generic files.
> However,
> > the properties relating to instruments are empty - hence broken
> instruments
> >
> > :-). But if they work for you, the problem must be local, so I'll keep
> >
> > looking. Since it's all the instruments the common factor is the
> electrical
> > supply, so I'll start there.
> 
> I would suggest that you try to create custom systems and instrumentation
> configuration files for your aircraft. Use the generic ones as a start. I
> think that you should remove the GPS instrument ;-) and maybe the nav
> radios.
> 

I have checked the path - I'm was the downloaded cvs data from 1522 Monday.
I have re-downloaded cvs data and source this morning and recompiled. 

I've changed the hunter to use the generic files - it already has custom
electrics and instrumentation - still the altimeter, ASI, climb-rate and
turn and slip don't work. Hsi and directional gyro work, but they take their
input from the 'wrong' place. In the property browser all the instrument
values are undefined.

The P51d instruments also don't work, in fact all the instruments I have
tested don't work. I suspect the instruments generically don't work.

Can you reconfirm that all the hunter/seahawk/P51 instruments work for you?
And did you change anything in the hunter files?

I've gone back to cvs update as of 15 Oct: all the aircraft work correctly.
I conclude that this problem is caused by your new code. Unless you can
confirm that the instruments work in all models in your location, or tell me
exactly what I have to do to correct the situation, I strongly suggest that
whatever has been done, be undone. 

Regards,

Vivian 

P.S. I have wasted a day's work on this issue, and my teddy bear has now
been thrown out of the pram.










------------------------------

Message: 4
Date: Wed, 20 Oct 2004 12:08:15 +0200
From: "Luca Masera" <[EMAIL PROTECTED]>
Subject: [Flightgear-devel] kr_87 linker problems solved: was an error
        in      "instrument_mgr.cxx"
To: "flightgear-devel" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1

I've solved the linker error in the kr_87 object. It's an error in the file 
instrument_mgr.cxx into the 
include list, caused by the include of a the file kr_87.cxx instead of kr_87.hxx. 
The other problems still remain.

Bye, Luce



____________________________________________________________
Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. 
Abbonati subito su http://www.libero.it 





------------------------------

Message: 5
Date: Wed, 20 Oct 2004 11:12:11 +0100
From: "David Luff" <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] TaxiDraw-0.2.2 released
To: "FlightGear developers discussions"
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"



On 10/19/04 at 11:57 AM Chris Metzler wrote:

>
>I'm wondering whether we know what the X-Plane format really *is*.
>Since the beginning of September, Robin Peel has been saying that a
>new set of files are coming out "next weekend, September 18."  But he
>also says that these files won't work at all with earlier versions
>of X-Plane.  That may simply be because of the new information content
>in fields that were basically dummy (see below) choking reads that
>don't know how to handle them; but it made me wonder if there's a file
>format change coming up.  At the very least, his comments about being
>able to declare aprons separate from taxiways suggest a new record type.
>

Well, I guess we'll find out eventually.  Converters are easy to write, if
somewhat tedious.  The current X-Plane format contains a flag indicating
whether to include runway distance remaining signs or not, so the change to
it should be good for you in that respect.

>On a related note, since the X-Plane files are apparently going to support
>this soon, is there any possibility of being able to "label" taxiways with
>identifiers (e.g. "taxiway A")?  I know that right now, we don't do
>anything with that information; but we might in the future, with sign
>placement or ground control instructions or whatever, and if people have
>that information and the opportunity to add it to the database, we might
>as well, rather than having to go back and add it later.  Something
>along these lines (re: taxiways and aprons):
>
>http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029106.htm
l
>

I think that your idea to put a taxiway designator in the 'xxx' (bet this
message gets flagged as spam now!) part of the record is an excellent one.
The downside of course is that it would require X-Plane itself to
understand it before it could be applied to the master dataset.  On the
other hand, genapts could be made to understand it as an extension to the
default format.  And if as you say the X-Plane format is likely to contain
it soon then that's excellent.

What I suggest is that the TaxiDraw project file be allowed to keep extra
information such as this, perhaps in xml format.  Then, when exporting one
can simply export the information relevant at the time for the format
exported to.  One could possible generate the airport signage directly from
the TaxiDraw project files, or maybe by exporting the extra data into the
X-Plane data as an extension that genapts understands.  Once X-Plane format
officially includes it, it can be exported from the TaxiDraw project files
into whatever format it uses to understand it.

Some of the other issues you bring up in the archived post you mention are
similar to those that Paul Surgeon brings up in this thread - I'll think
about it and reply again.

Cheers - Dave



This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.




------------------------------

Message: 6
Date: Wed, 20 Oct 2004 12:53:49 +0200
From: Frederic Bouvier <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] kr_87 linker problems solved: was an
        error in        "instrument_mgr.cxx"
To: FlightGear developers discussions
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Selon Luca Masera <[EMAIL PROTECTED]>:

> I've solved the linker error in the kr_87 object. It's an error in the file
> instrument_mgr.cxx into the
> include list, caused by the include of a the file kr_87.cxx instead of
> kr_87.hxx.
> The other problems still remain.

It's already fixed in CVS.

-Fred



------------------------------

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


End of Flightgear-devel Digest, Vol 18, Issue 53
************************************************

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to