[Flightgear-devel] [Fwd: PLEASE HELP - compiling SimGear]

2004-06-04 Thread Joe
Apparently it's not the compiler, either.  I noticed that a lot of folks 
were having this sort of problem with the 3.3.1 version of gcc, so I 
rebuilt to 3.3.2 (a version that other people had had success with, even 
though it's not the latest) and it's still throwing the same errors at me.

Does anyone have some hints?
-j
 Original Message 
Subject: PLEASE HELP - compiling SimGear
Date: Thu, 03 Jun 2004 20:20:08 -0400
From: Joe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I'm trying to compile SimGear.  When the make hits the clouds3d
directory I get a screen full of errors that tell me that various
symbols are being redeclared as different kind of symbol, all of them
in extgl.c.  All the errors refer to symbols in gl.h: glBlendColor,
glBlendEquation, glDrawRangeElements, etc - there are a lot of them.
Can SOMEONE tell me why this is happening?
The env:
cygwin, rebuilt earlier today using the latest components (including
GLUT 3.7.6)
gcc 3.3.1
SimGear was checked out from CVS at about 5pm
plib 1.8.3
zlib 1.2.1
Thanks for your help.
-j

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


[Flightgear-devel] PLEASE HELP - compiling SimGear

2004-06-03 Thread Joe
I'm trying to compile SimGear.  When the make hits the clouds3d 
directory I get a screen full of errors that tell me that various 
symbols are being redeclared as different kind of symbol, all of them 
in extgl.c.  All the errors refer to symbols in gl.h: glBlendColor, 
glBlendEquation, glDrawRangeElements, etc - there are a lot of them. 
Can SOMEONE tell me why this is happening?

The env:
cygwin, rebuilt earlier today using the latest components (including 
GLUT 3.7.6)
gcc 3.3.1
SimGear was checked out from CVS at about 5pm
plib 1.8.3
zlib 1.2.1

Thanks for your help.
-j

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


[Flightgear-devel] Re: ..why C++ and not C?

2002-05-28 Thread joe mangan



On Sat, 27 Apr 2002 01:57:09 -0500 Jonathan Polleywrote 


When you state your concerns about the FAA, 
I assume that you are talking about avionics software, probably DO-178B 
level C or higher.The vast majority of modern (1987+) avionics 
software that I have seen is in Ada, largely due to the structure that 
is built into the language. With Ada's strong typing and package 
structure, you really need to work to do something bad. The little 
bit of C software that we let wind up in our final software is *very* 
process driven. This includes design reviews, code reviews, test 
plans at design time, and test procedures that are traceable back to 
top-level requirements. While our Ada software goes through these 
same steps, extra care is taken with C (we restrict what can be used), 
largely due to the lack of safeguards built into the language.The 
biggest problem I see with C++ and the FAA is that it is VERY hard to 
guarantee that C++ will not do any dynamic memory allocation. If 
you step through the STL code with a debugger you will be amazed at how 
much is going on there (strings are nasty). Since avionics are 
embedded systems, the freeing of dynamic memory is a Very Bad 
Thing.If you are developing software that will be used to test 
avionics software, then the rules change. The same is true 
for level D or lower software. With test applications, you need to 
go through a verification process, which my team will be doing very 
shortly. While the process demands are not as strict as it is for 
the flight software, I tend to require the same level of process as our 
flight code. We tend to share people across programs, and you 
never quite know where your software will be used next.



I think I can safely say that FlightGear will 
never be airworthy (unless it is level E, which, in this case, means it 
will not be used for flight). There are no documented 
requirements, design, evidence of peer reviews, interface documentation, 
test procedures (especially ones mapped to the requirements), etc. 
While you could, in theory, spend enough money to certify almost any 
code, it is best if you think about airworthiness from the onset. 
The structural coverage alone would be prohibitive (i.e., prove that 
every branch of every line of code maps to some requirement and that you 
have a test that exercises them).

Standards for application to general aviation 
aircraft have been revised as to reduce the burden for 
certification of specific classes of avionics 
equipment.

AC 29-1309

An alternative would be to consider an effort to 
certify FlightGear as a Flight Training Device under 
AC 120-45A

Jonathan, what is your day job ?

Joe Mangan