Re: [Flightgear-devel] Migration from cockpit to instrumentation

[David Megginson]

n Wed, 10 Nov 2004 23:45:29 +0100, Roy Vegard Ovesen
<[EMAIL PROTECTED]> wrote:

> I'm migrating stuff from the cockpit directory to the instrumentation
> directory. Specifically I'm migration the stuff in the radio stack. My
> question is this: should I also move the properties from /radios/*
> to /instrumentation/*?

I had forgotten that there still was anything in the cockpit directory
-- that's some pretty rusty code.  Thanks for looking into this.


All the best,


David

-- 
http://www.megginson.com/

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

Re: [Flightgear-devel] Plea for help: geometry/trigonometry prob lem

[David Megginson]

On Thu, 11 Nov 2004 09:10:35 +1100, Curtin, Robert
<[EMAIL PROTECTED]> wrote:

> I just stumbled across this thread and couldn't figure out whether it was
> resolved or not. Not being overly familiar with FlightGear, I'm not even
> sure what the inputs to this problem were. This is how I would approach it
> though... 

Thanks, Rob.  I have something that seems to work well now in
src/Instrumentation/mag_compass.cxx -- I'd be grateful if you could
take a look and see if it's possible to improve or at least clean up
the calculations.


Thanks, and all the best,


David

-- 
http://www.megginson.com/

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

Re: [Flightgear-devel] Migration from cockpit to instrumentation

[Curtis L. Olson]

Roy Vegard Ovesen wrote:
I'm migrating stuff from the cockpit directory to the instrumentation 
directory. Specifically I'm migration the stuff in the radio stack. My 
question is this: should I also move the properties from /radios/* 
to /instrumentation/*?

I think this is a good idea, because
- The adf and dme in the instrumentation directory have their properties 
in /instrumentation, and they are radios.
- The stuff in the radio stack (navcom, kt70 transponder, market beacon and 
another older dme) have properties in both /radios and /instrumentation. The 
serviceable property is in /instrumentation.

The downside is of course that all the radio instrument panels will be broken, 
but this can easily be fixed with a quick grep through the data/Aircrafts 
directory.
 

Roy,
If you fiddle with this, there is a bunch of stuff in 
Network/atc610x.[hc]xx that mustn't get broken.

Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] nurbs headaches

[Lee Elliott]

On Tuesday 09 November 2004 15:38, Curtis L. Olson wrote:
> Gerhard Wesp wrote:
> >Hmm...  About what resolution are we talking here?
>
> Generally, 90m SRTM.
>
> >What additional data do you have available for the runways? 
> > I guess you have it's position (two endpoints?  center
> > point, direction, length?) and ``elevation''?  Commonly, the
> > runway elevation at both thresholds is given in the approach
> > plates, is this data available?
>
> Often, elevation of each touch down point is available,
> although that is not included in Robin's database.
>
> >How about the following KISS solution:  Do a first- or
> > second-order approximation of the elevation of the
> > centerline (least squares). Define the runway using its
> > width, this centerline and no sideways slope.
>
> This [wc]ould cause problems in places where runways intersect
> and doesn't account for the surface of all the taxiways and
> the rest of the airport, and it doesn't help blend the airport
> cleanly into the surrounding terrain.
>
> For what it's worth, I believe I have beaten the nurbs
> approach into submission (mostly) and I hope that the next
> scenery release will be an incremental improvement over the
> last one, with better surface matching to the underlying dem,
> but with fewer odd artificats (I believe I have eliminated
> those 5m drop offs that occured in the middle of a very few
> runways.)
>
> Regards,
>
> Curt.

Hello Curt,

I might be a bit late on this one - you say you've beaten the 
problem now.

I've used nurbs and splines quite a lot in 3d modelling but don't 
have any programming experience with them.

First of all, when I use them for modelling I don't normally 
expect the resulting curves to pass through the knots/control 
points.  However, with the software I use I can 'invert' the 
control points so that the curve _does_ pass through them.  The 
difference is like drawing a circle within a square or regular 
polygon, so that the curve touches the sides, or outside the 
square or polygon, so that it touches the points.

I'd imagine that the data you've got - an array of x,y,z points -  
would be treated as the control points for the curves and so I 
wouldn't expect the curves to pass through them.

It's also possible to use double or triple points to control the 
'sharpness' of the curve.  They'd also commonly be used along 
the edges of a nurb or spline patch to make sure the patch 
actually extends to the edges.

Dunno if that's any help - it's one of those things that are 
easier to do than explain.

LeeE

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

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Arthur Wiebe]

I have built PLIB 1.8.3 and SimGear 0.3.7.
But building FlightGear 0.9.6 has not yet been successful.

I used ./configure --prefix=$BUILDDIR --without-x
and then plain make.
It looked like everything was going to work until... here's a cut of
the output leading up to the error:

if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
 -I/fgfs/include  -I/usr/X11R6/include -D_REENTRANT -MT puList.o -MD
-MP -MF ".deps/puList.Tpo" -c -o puList.o puList.cxx; \
then mv -f ".deps/puList.Tpo" ".deps/puList.Po"; else rm -f
".deps/puList.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
 -I/fgfs/include  -I/usr/X11R6/include -D_REENTRANT -MT AirportList.o
-MD -MP -MF ".deps/AirportList.Tpo" -c -o AirportList.o
AirportList.cxx; \
then mv -f ".deps/AirportList.Tpo" ".deps/AirportList.Po"; else rm -f
".deps/AirportList.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
 -I/fgfs/include  -I/usr/X11R6/include -D_REENTRANT -MT layout.o -MD
-MP -MF ".deps/layout.Tpo" -c -o layout.o layout.cxx; \
then mv -f ".deps/layout.Tpo" ".deps/layout.Po"; else rm -f
".deps/layout.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
 -I/fgfs/include  -I/usr/X11R6/include -D_REENTRANT -MT layout-props.o
-MD -MP -MF ".deps/layout-props.Tpo" -c -o layout-props.o
layout-props.cxx; \
then mv -f ".deps/layout-props.Tpo" ".deps/layout-props.Po"; else rm
-f ".deps/layout-props.Tpo"; exit 1; fi
rm -f libGUI.a
ar cru libGUI.a new_gui.o dialog.o menubar.o gui.o gui_funcs.o
gui_local.o mouse.o preset_dlg.o prop_picker.o sgVec3Slider.o
trackball.o puList.o AirportList.o layout.o layout-props.o
ranlib libGUI.a
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
 -I/fgfs/include  -I/usr/X11R6/include -D_REENTRANT -MT layout-test.o
-MD -MP -MF ".deps/layout-test.Tpo" -c -o layout-test.o
layout-test.cxx; \
then mv -f ".deps/layout-test.Tpo" ".deps/layout-test.Po"; else rm -f
".deps/layout-test.Tpo"; exit 1; fi
g++  -I/usr/X11R6/include -D_REENTRANT  -L/fgfs/lib -o layout-test 
layout-test.o libGUI.a -lsgprops -lsgdebug -lsgstructure -lsgmisc
-lsgxml -lplibpw -lplibpu -lplibfnt -lplibul -framework GLUT
-framework OpenGL -framework AGL -framework Carbon -lobjc
ld: Undefined symbols:
fntTexFont::load(char const*, unsigned int, unsigned int)
make[2]: *** [layout-test] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Do you have any ideas or had this error yourself?

By the way, Mac OS X packages of PLIB are at
http://awiebe.blogdns.net/download/PLIB/MacOSX/

Hoping to add a flightgear and simgear package as well soon.

On Wed, 10 Nov 2004 16:03:39 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Arthur
> 
> I'm glad plib built for you. I only put plib and other flightgear files
> in a local tree and use --prefix so configure can find them. Also that
> way, I don't have to worry about old versions of plib that might be on
> my system somewhere.
> 
> if you use --prefix with a non-system directory, you can avoid having
> to use sudo make install for library installation also.
> 
> Lots of people on the list have run into problems related to old(er)
> versions of libraries on their systems in multiple paths.  I'm sure
> that I ran into this one before I started using --prefix
> 
> On Nov 10, 2004, at 2:49 PM, Arthur wrote:
> 
> > Date: Wed, 10 Nov 2004 14:49:32 -0500
> > From: Arthur Wiebe <[EMAIL PROTECTED]>
> > Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X
> > To: FlightGear developers discussions
> >   <[EMAIL PROTECTED]>
> > Message-ID: <[EMAIL PROTECTED]>
> > Content-Type: text/plain; charset=US-ASCII
> 
> 
> >
> > Well... I got simgear configured.
> >
> > Before I didn't specify --prefix for plib or simgear. Now I made a
> > directory called fgfs in / and install plib  there and then specified
> > that plib was installed there when configuring simgear and used the
> > same prefix for simgear. Now it worked.
> > This leads me to thinking it was a crazy permissions problem!
> >
> > Well at least it works now and I will be making a Mac OS X installer
> > package for plib 1.8.3 and posting it online for other people like me.
> >
> > Next step is to get simgear and flightgear to compile. I guess you'll
> > hear from me again soon.
> >
> 
> good luck! Use the same --prefix for plib, simgear and flightgear. Is
> everything building OK now? Remember you can't mix and match release
> and CVS versions, either release plib, simgear and flightgear source OR
> CVS plib, simgear, flightgear source.
> 
> There is also talk on the list recently about file name collisions on
> case preserving but not case significant file systems (like cygwin and
> mac os x). You'll see this when you're downloading the data from cvs
> under mac os x, if you're using HFS+ as opposed to a *nix file system
> on your Mac with a few files unless they've been fixed already.
> 
> Anyway you want CVS

[Flightgear-devel] Migration from cockpit to instrumentation

[Roy Vegard Ovesen]

I'm migrating stuff from the cockpit directory to the instrumentation 
directory. Specifically I'm migration the stuff in the radio stack. My 
question is this: should I also move the properties from /radios/* 
to /instrumentation/*?

I think this is a good idea, because
- The adf and dme in the instrumentation directory have their properties 
in /instrumentation, and they are radios.
- The stuff in the radio stack (navcom, kt70 transponder, market beacon and 
another older dme) have properties in both /radios and /instrumentation. The 
serviceable property is in /instrumentation.

The downside is of course that all the radio instrument panels will be broken, 
but this can easily be fixed with a quick grep through the data/Aircrafts 
directory.

-- 
Roy Vegard Ovesen

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

[Flightgear-devel] Plea for help: geometry/trigonometry prob lem

[Curtin, Robert]

I just stumbled across this thread and couldn't 
figure out whether it was resolved or not. Not being overly familiar with 
FlightGear, I'm not even sure what the inputs to this problem were. This is how I would approach it 
though...
Usually mag heading is calculated from a magnetic 
field model, eg, WMM 2000.
The main output of this model is the magnetic field 
vector, B, in geodetic (d) axes: [Bx_d By_d Bz_d].
Magnetic declination (magvar) and inclination (dip) 
are trig functions of these coordinates:
magvar = atan2(By_d/Bx_d)
dip = atan(Bz_d/sqrt(Bx_d^2 + By_d^2)) = 
asin(Bz_d/|B|)
Transforming the vector B into other coordinate 
systems gives other parameters of interest, eg:
Magnetic heading is given by psiM = 
-atan2(By_h/Bx_h), where h is for horizontal axes.
Indicated heading could be psiMI = -atan2(By_b/Bx_b), 
where b is for body axes (for a needle rotating in the plane of the 
wings).
To transform the vector B between different 
coordinate systems, you need the relevant direction cosine matrices:
T_bd=R3(phi)R2(theta)R1(psi)
T_bh=R3(phi)R2(theta)R1(0)
T_hd=R3(0)R2(0)R1(psi)
(notation: T_bd is body from geodetic axes, R1 is the 
yaw rotation matrix, R2 is the pitch rotation matrix and R3 is the roll rotation 
matrix.)
This provides the basis for relating everything to 
everything else. If you are starting with the magnetic field vector, the 
calculations are fairly straight forward. If you only have magvar and dip, then 
it's a bit more fiddly. If you don't want to use a matrix class, you can expand 
out the DCMs.
Regards, Rob
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[ima . sudonim]

Arthur
I'm glad plib built for you. I only put plib and other flightgear files 
in a local tree and use --prefix so configure can find them. Also that 
way, I don't have to worry about old versions of plib that might be on 
my system somewhere.

if you use --prefix with a non-system directory, you can avoid having 
to use sudo make install for library installation also.

Lots of people on the list have run into problems related to old(er) 
versions of libraries on their systems in multiple paths.  I'm sure 
that I ran into this one before I started using --prefix

On Nov 10, 2004, at 2:49 PM, Arthur wrote:
Date: Wed, 10 Nov 2004 14:49:32 -0500
From: Arthur Wiebe <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X
To: FlightGear developers discussions
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII
Well... I got simgear configured.
Before I didn't specify --prefix for plib or simgear. Now I made a
directory called fgfs in / and install plib  there and then specified
that plib was installed there when configuring simgear and used the
same prefix for simgear. Now it worked.
This leads me to thinking it was a crazy permissions problem!
Well at least it works now and I will be making a Mac OS X installer
package for plib 1.8.3 and posting it online for other people like me.
Next step is to get simgear and flightgear to compile. I guess you'll
hear from me again soon.
good luck! Use the same --prefix for plib, simgear and flightgear. Is 
everything building OK now? Remember you can't mix and match release 
and CVS versions, either release plib, simgear and flightgear source OR 
CVS plib, simgear, flightgear source.

There is also talk on the list recently about file name collisions on 
case preserving but not case significant file systems (like cygwin and 
mac os x). You'll see this when you're downloading the data from cvs 
under mac os x, if you're using HFS+ as opposed to a *nix file system 
on your Mac with a few files unless they've been fixed already.

Anyway you want CVS plib to have Olivier's great joystick fixes anyway. 
I'm not sure they're in a release yet. I use the CVS source tree, which 
a few times a year gets into a non-buildable state for a day or two but 
is not usually a problem.

I don't have Mac os X installs for anything, but one of the other Mac 
people (Jonathan, perhaps?) had created a Mac os X cocoa executable for 
FGFS. I don't recall if they had an app for installation, however. I 
think it was just drag and drop.  I don't know if this app has been 
updated.

I'm assuming you no longer need ./lib/libplibXXX and ./include/plib 
sent to you? 8-)

Have fun and please let the list know how it goes.
Provided you've got the dependencies installed, the Mac OS X build goes 
just like any other *nix clone 8-). Hopefully, you'll have no build 
problems once you're using --prefix.  Just remember to build flightgear 
using ./configure --without-x unless you want to use X11 on mac os x 
(which is NOT installed by default).

There, I think that's all the mac related screwups, I've done 8-)
Enjoy the world's best Mac OS X opensource flightsim...
Now if someone would just do Washington, DC scenery for flightgear. I 
used to have a nice DC add-on for XPlane...

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

Re: [Flightgear-devel] Building FlightGear on Mac OSX

[Arthur Wiebe]

I found another way to get simgear to build using GCC 3.3 and bash.

First set two environment variables:
export CFLAGS=-I/usr/X11R6/include
export CXXFLAGS=-I/usr/X11R6/include

and then run configure with the --with-x flag:
./configure --prefix=$BUILDDIR --with-x

I was able to build simgear like that without having to modify any
code. (I got it from looking at a darwinports port file)

I havn't tried building flightgear yet though.


On Wed, 10 Nov 2004 12:43:37 -0800, Adam Dershowitz
<[EMAIL PROTECTED]> wrote:
> I have made a bunch of progress, but have not yet gotten everything to work.
> So I still have some questions.
> I hope by posting this I can help others compile stuff, and also get some
> help to finish up the compile.
> Despite what the users guide says for building under OSX I have been using
> gcc 3.3.
> 
> I am sorry for the length of this email, but I have included some diffs and
> compile errors in detail.
> 
> Here are the steps that I have had to go through:
> 
>   export BUILDDIR=/Users/dersh/Programming/fgdev
> 
>   Download plib 1.8.3
> 
> Made the following changes to the files:
> 
> diff jsMacOSX.cxx jsMacOSX_org.cxx
> 
> 17,19c17
> < //int jsJoystick::kNumDevices = 32 ;
> < int jsJoystick::kNumDevices = JS_MAX_OSX_DEVICES ;
> <
> ---
> > int jsJoystick::kNumDevices = 32 ;
> 21,22c19
> < //io_object_t jsJoystick::ioDevices[kNumDevices];
> < io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
> ---
> > io_object_t jsJoystick::ioDevices[kNumDevices];
> 132,133c129,130
> <   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
> <   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID), &hidDev);
> ---
> >   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
> >   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID),
> &(LPVOID)hidDev);
> 
> The last change above was because I kept getting a compile error:
> jsMacOSX.cxx: In member function `void jsJoystick::open()':
> jsMacOSX.cxx:133: error: non-lvalue in unary `&'
> 
> I don't like removing a cast without understanding the implications, but I
> did it anyway, just get it to compile.  So my first question is really a
> plib question, but it is why there is the LPVOID, and is it OK to just
> remove it?
> 
> diff js.h js_org.h
> 35,36d34
> < #define JS_MAX_OSX_DEVICES  32
> <
> 97c95
> <   static  int kNumDevices;
> ---
> >   static const int kNumDevices;
> 99,100c97
> < //  static io_object_t ioDevices[kNumDevices];
> < static io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
> ---
> >   static io_object_t ioDevices[kNumDevices];
> 
> But then building plib works fine:
> ./autogen.sh
> ./configure -prefix=$BUILDDIR
> make install
> 
> Next to build SimGear I kept getting stream related errors.  I made the
> following change to simgear/compiler.h and then I was able to get it to
> build as well:
> 
> diff compiler.h "compiler org.h"
> 82c82
> < #ifdef __GNUC__ || __APPLE__
> ---
> > #ifdef __GNUC__
> 
> It seems that even though I am using gcc, the right flag is not being set,
> so each of the test programs, that does require streams, and other standard
> IO kinds of things gave link errors.
> 
> ./autogen.sh
> ./configure -prefix=$BUILDDIR
> make install
> 
> Finally, when I try to build FlightGear I can compile everything, but the
> final like fails.
> 
> I have been doing:
> /autogen.sh
>  ./configure --prefix=$BUILDDIR --with-threads --without-x
> make install
> 
> And here is the final link warnings and errors:
> 
> g++ -DPKGLIBDIR=\"/Users/dersh/Programming/fgdev/share/FlightGear\" -g -O2
> -D_REENTRANT  -L/Users/dersh/Programming/fgdev/lib -o fgfs  bootstrap.o
> ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a
> ../../src/ATC/libATC.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/ExternalPipe/libExternalPipe.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/FDM/SP/libSPFDM.a ../../src/GUI/libGUI.a
> ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a
> ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a
> ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a
> ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a
> ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a
> ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a
> ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a
> ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a
> ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky

Re: [Flightgear-devel] Building FlightGear on Mac OSX

[Jon S Berndt]

On Wed, 10 Nov 2004 12:43:37 -0800
 Adam Dershowitz <[EMAIL PROTECTED]> wrote:
Finally, I noticed something else. I am not sure who the maintaineris.
That would probably be me ... :-)
But in JSBSim/Makefile.solo (not required for FG, but good for other
things.)  there is a typo. That will not allow for a building of 
JSBSim separately.

It reads:
JSBSim : $(JSBSim_objects) JSBSim.o libFCSComponents.a
   $(CC) $(INCLUDES) $(CCOPTS) $(LINKDIR) $(JSBSim_objects) JSBSim.o
-oJSBSim -lm -lFCSComponents
But that will not work.
It should have a space after the -o.  So it should be:
JSBSim : $(JSBSim_objects) JSBSim.o libFCSComponents.a
   $(CC) $(INCLUDES) $(CCOPTS) $(LINKDIR) $(JSBSim_objects) JSBSim.o 
-o JSBSim -lm -lFCSComponents

How can we get that fixed in the CVS version?
Interesting. It's been working on other platforms for years like that. 
I don't know if there is a standard for that or not - that is, is a 
space required between the "-o" and the argument? Regardless, I can go 
ahead and change that in our JSBSim CVS file.

Also, when you notice a bug like that, there is a bug reprting 
mechanism on the JSBSim web site at www.jsbsim.org. I like to have 
bugs entered there, so they don't get lost in the shuffle.

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

Re: [Flightgear-devel] Building FlightGear on Mac OSX

[Adam Dershowitz]

I have made a bunch of progress, but have not yet gotten everything to work.
So I still have some questions.
I hope by posting this I can help others compile stuff, and also get some
help to finish up the compile.
Despite what the users guide says for building under OSX I have been using
gcc 3.3.

I am sorry for the length of this email, but I have included some diffs and
compile errors in detail.


Here are the steps that I have had to go through:

  export BUILDDIR=/Users/dersh/Programming/fgdev

  Download plib 1.8.3

Made the following changes to the files:

diff jsMacOSX.cxx jsMacOSX_org.cxx

17,19c17
< //int jsJoystick::kNumDevices = 32 ;
< int jsJoystick::kNumDevices = JS_MAX_OSX_DEVICES ;
<   
---
> int jsJoystick::kNumDevices = 32 ;
21,22c19
< //io_object_t jsJoystick::ioDevices[kNumDevices];
< io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
---
> io_object_t jsJoystick::ioDevices[kNumDevices];
132,133c129,130
<   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
<   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID), &hidDev);
---
>   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
>   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID),
&(LPVOID)hidDev);

The last change above was because I kept getting a compile error:
jsMacOSX.cxx: In member function `void jsJoystick::open()':
jsMacOSX.cxx:133: error: non-lvalue in unary `&'

I don't like removing a cast without understanding the implications, but I
did it anyway, just get it to compile.  So my first question is really a
plib question, but it is why there is the LPVOID, and is it OK to just
remove it?

diff js.h js_org.h
35,36d34
< #define JS_MAX_OSX_DEVICES  32
< 
97c95
<   static  int kNumDevices;
---
>   static const int kNumDevices;
99,100c97
< //  static io_object_t ioDevices[kNumDevices];
< static io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
---
>   static io_object_t ioDevices[kNumDevices];

But then building plib works fine:
./autogen.sh
./configure -prefix=$BUILDDIR
make install

Next to build SimGear I kept getting stream related errors.  I made the
following change to simgear/compiler.h and then I was able to get it to
build as well:

diff compiler.h "compiler org.h"
82c82
< #ifdef __GNUC__ || __APPLE__
---
> #ifdef __GNUC__

It seems that even though I am using gcc, the right flag is not being set,
so each of the test programs, that does require streams, and other standard
IO kinds of things gave link errors.

./autogen.sh
./configure -prefix=$BUILDDIR
make install

Finally, when I try to build FlightGear I can compile everything, but the
final like fails.

I have been doing:
/autogen.sh
 ./configure --prefix=$BUILDDIR --with-threads --without-x
make install

And here is the final link warnings and errors:

g++ -DPKGLIBDIR=\"/Users/dersh/Programming/fgdev/share/FlightGear\" -g -O2
-D_REENTRANT  -L/Users/dersh/Programming/fgdev/lib -o fgfs  bootstrap.o
../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a
../../src/ATC/libATC.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/ExternalPipe/libExternalPipe.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/FDM/SP/libSPFDM.a ../../src/GUI/libGUI.a
../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a
../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a
../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a
../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a
../../src/Scripting/libScripting.a ../../src/Sound/libSound.a
../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a
../../src/Replay/libReplay.a ../../src/Systems/libSystems.a
../../src/Time/libTime.a ../../src/Traffic/libTraffic.a
../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky
-lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio
-lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc
-lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment
-lsgthreads -lpthread  -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg
-lplibsg -lplibul  -lz -framework GLUT -framework OpenGL -framework AGL
-framework Carbon -lobjc -framework IOKit -framework OpenAL
ld: warning multiple definitions of symbol _glutWireTorus
/Users/dersh/Programming/fgdev/lib/libsgclouds3d.a(glut_shapes.o) definition
of _glutWireTorus in section (__TEXT,__text)
/System/Library/Frameworks/GLUT.framework/GLUT(single module) definition of
_glutWireTorus
ld: warning multiple definitions of symbol _glutSolidDodecahedr

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Arthur Wiebe]

Now to building simgear on Mac OS X. I get the following output:

source='matlib.cxx' object='matlib.o' libtool=no \
depfile='.deps/matlib.Po' tmpdepfile='.deps/matlib.TPo' \
depmode=gcc3 /bin/sh ../../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../../simgear -I../../.. 
-I/fgfs/include  -g -O2 -D_REENTRANT -c -o matlib.o `test -f
'matlib.cxx' || echo './'`matlib.cxx
matlib.cxx:36:19: GL/gl.h: No such file or directory
make[4]: *** [matlib.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

./configure goes fine. But I can't run make without the above. This is
with GCC 3.3. I seem to have lost my GCC 2.95.2 installation so I have
to install it before I can try with that.


On Wed, 10 Nov 2004 14:49:32 -0500, Arthur Wiebe <[EMAIL PROTECTED]> wrote:
> Well... I got simgear configured.
> 
> Before I didn't specify --prefix for plib or simgear. Now I made a
> directory called fgfs in / and install plib  there and then specified
> that plib was installed there when configuring simgear and used the
> same prefix for simgear. Now it worked.
> This leads me to thinking it was a crazy permissions problem!
> 
> Well at least it works now and I will be making a Mac OS X installer
> package for plib 1.8.3 and posting it online for other people like me.
> 
> Next step is to get simgear and flightgear to compile. I guess you'll
> hear from me again soon.
> 
> 
> 
> 
> On Wed, 10 Nov 2004 14:32:39 -0500, Arthur Wiebe <[EMAIL PROTECTED]> wrote:
> > I looked into the config.log file and it doesn't make much sense:
> >
> > ## --- ##
> > ## confdefs.h. ##
> > ## --- ##
> >
> > #define HAVE_INTTYPES_H 1
> > #define HAVE_LIBPTHREAD 1
> > #define HAVE_MEMORY_H 1
> > #define HAVE_STDINT_H 1
> > #define HAVE_STDLIB_H 1
> > #define HAVE_STRINGS_H 1
> > #define HAVE_STRING_H 1
> > #define HAVE_SYS_STAT_H 1
> > #define HAVE_SYS_TYPES_H 1
> > #define HAVE_UNISTD_H 1
> > #define PACKAGE "SimGear"
> > #define PACKAGE_BUGREPORT ""
> > #define PACKAGE_NAME ""
> > #define PACKAGE_STRING ""
> > #define PACKAGE_TARNAME ""
> > #define PACKAGE_VERSION ""
> > #define STDC_HEADERS 1
> > #define VERSION "0.3.7"
> > #endif
> > #ifdef __cplusplus
> > extern "C" void std::exit (int) throw (); using std::exit;
> >
> > configure: exit 1
> >
> > And using --plib-prefix=/usr/ did not work. It resulted in:
> > configure: error: unrecognized option: --plib-prefix=/usr/
> > Try `./configure --help' for more information.
> >
> > I got PLIB 1.8.3 to compile thanks to Adam. But that didn't help
> > either. I think I will try to get the release version of simgear
> > instead of getting it from CVS. Don't think that will have any effect
> > though.
> >
> > I'm also going to try to use --prefix=/onepath for plib and simgear.
> > See if that works.
> >
> > Thanks for the replies!
> >
> >
> >
> >
> > On Wed, 10 Nov 2004 19:17:06 -, Giles Robertson
> > <[EMAIL PROTECTED]> wrote:
> > > I've found on some pseudo-POSIX Windows systems that the build only
> > > finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be
> > > what it takes; and it may be similar on OS X.
> > >
> > > The other tactic is to specify --prefix=/fg or some other value for
> > > every compile; PLIB, SimGear, FGFS.
> > >
> > > My 2 cents.
> > >
> > > Giles Robertson
> > >
> > >
> > >
> > > -Original Message-
> > > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]
> > > Sent: 10 November 2004 18:59
> > > To: FlightGear developers discussions
> > > Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X
> > >
> > > Arthur Wiebe wrote:
> > >
> > > >Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
> > > >straight from CVS 2004-11-08.
> > > >
> > > >Looking in /usr/include/plib and /usr/lib/ it looks like plib is
> > > installed.
> > > >
> > > >The only problem I now have is when trying to configure simgear from
> > > >CVS (same date) I get:
> > > >
> > > >checking plib/ul.h usability... no
> > > >checking plib/ul.h presence... yes
> > > >configure: WARNING: plib/ul.h: present but cannot be compiled
> > > >configure: WARNING: plib/ul.h: check for missing prerequisite
> > > headers?
> > > >configure: WARNING: plib/ul.h: see the Autoconf documentation
> > > >configure: WARNING: plib/ul.h: section "Present But Cannot Be
> > > Compiled"
> > > >configure: WARNING: plib/ul.h: proceeding with the preprocessor's
> > > result
> > > >configure: WARNING: plib/ul.h: in the future, the compiler will take
> > > precedence
> > > >configure: WARNING: ## --
> > > ##
> > > >configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.
> > > ##
> > > >configure: WARNING: ## --
> > > ##
> > > >checking for plib/ul.h... yes
> > > >checking for plib 1.6.0 or newer... wrong version
> > > >configure: error: Install plib 1.6.0 or later first...
> > > >
> > > >That

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Arthur Wiebe]

Well... I got simgear configured.

Before I didn't specify --prefix for plib or simgear. Now I made a
directory called fgfs in / and install plib  there and then specified
that plib was installed there when configuring simgear and used the
same prefix for simgear. Now it worked.
This leads me to thinking it was a crazy permissions problem!

Well at least it works now and I will be making a Mac OS X installer
package for plib 1.8.3 and posting it online for other people like me.

Next step is to get simgear and flightgear to compile. I guess you'll
hear from me again soon.


On Wed, 10 Nov 2004 14:32:39 -0500, Arthur Wiebe <[EMAIL PROTECTED]> wrote:
> I looked into the config.log file and it doesn't make much sense:
> 
> ## --- ##
> ## confdefs.h. ##
> ## --- ##
> 
> #define HAVE_INTTYPES_H 1
> #define HAVE_LIBPTHREAD 1
> #define HAVE_MEMORY_H 1
> #define HAVE_STDINT_H 1
> #define HAVE_STDLIB_H 1
> #define HAVE_STRINGS_H 1
> #define HAVE_STRING_H 1
> #define HAVE_SYS_STAT_H 1
> #define HAVE_SYS_TYPES_H 1
> #define HAVE_UNISTD_H 1
> #define PACKAGE "SimGear"
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE_NAME ""
> #define PACKAGE_STRING ""
> #define PACKAGE_TARNAME ""
> #define PACKAGE_VERSION ""
> #define STDC_HEADERS 1
> #define VERSION "0.3.7"
> #endif
> #ifdef __cplusplus
> extern "C" void std::exit (int) throw (); using std::exit;
> 
> configure: exit 1
> 
> And using --plib-prefix=/usr/ did not work. It resulted in:
> configure: error: unrecognized option: --plib-prefix=/usr/
> Try `./configure --help' for more information.
> 
> I got PLIB 1.8.3 to compile thanks to Adam. But that didn't help
> either. I think I will try to get the release version of simgear
> instead of getting it from CVS. Don't think that will have any effect
> though.
> 
> I'm also going to try to use --prefix=/onepath for plib and simgear.
> See if that works.
> 
> Thanks for the replies!
> 
> 
> 
> 
> On Wed, 10 Nov 2004 19:17:06 -, Giles Robertson
> <[EMAIL PROTECTED]> wrote:
> > I've found on some pseudo-POSIX Windows systems that the build only
> > finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be
> > what it takes; and it may be similar on OS X.
> >
> > The other tactic is to specify --prefix=/fg or some other value for
> > every compile; PLIB, SimGear, FGFS.
> >
> > My 2 cents.
> >
> > Giles Robertson
> >
> >
> >
> > -Original Message-
> > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]
> > Sent: 10 November 2004 18:59
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X
> >
> > Arthur Wiebe wrote:
> >
> > >Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
> > >straight from CVS 2004-11-08.
> > >
> > >Looking in /usr/include/plib and /usr/lib/ it looks like plib is
> > installed.
> > >
> > >The only problem I now have is when trying to configure simgear from
> > >CVS (same date) I get:
> > >
> > >checking plib/ul.h usability... no
> > >checking plib/ul.h presence... yes
> > >configure: WARNING: plib/ul.h: present but cannot be compiled
> > >configure: WARNING: plib/ul.h: check for missing prerequisite
> > headers?
> > >configure: WARNING: plib/ul.h: see the Autoconf documentation
> > >configure: WARNING: plib/ul.h: section "Present But Cannot Be
> > Compiled"
> > >configure: WARNING: plib/ul.h: proceeding with the preprocessor's
> > result
> > >configure: WARNING: plib/ul.h: in the future, the compiler will take
> > precedence
> > >configure: WARNING: ## --
> > ##
> > >configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.
> > ##
> > >configure: WARNING: ## --
> > ##
> > >checking for plib/ul.h... yes
> > >checking for plib 1.6.0 or newer... wrong version
> > >configure: error: Install plib 1.6.0 or later first...
> > >
> > >That has to mean something.
> > >
> > >I tried changing the version in ul.h but that didn't help :). Could
> > >you send me your compiled files (from /usr/lib/libplibXXX and
> > >/usr/include/plib) and see if if that works? I would love to make an
> > >installer package for Mac OS X which would install plib for other OSX
> > >users without having to compile it.
> > >
> > >
> >
> > The details of the configure script failure can be found in the
> > config.log file.  That may shed some light on exactly what is going
> > wrong.
> >
> > Curt.
> >
> > --
> > Curtis Olsonhttp://www.flightgear.org/~curt
> > HumanFIRST Program  http://www.humanfirst.umn.edu/
> > FlightGear Project  http://www.flightgear.org
> > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> > 2f585eeea02e2c79d7b1d8c4963bae2d
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL P

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Arthur Wiebe]

I looked into the config.log file and it doesn't make much sense:

## --- ##
## confdefs.h. ##
## --- ##

#define HAVE_INTTYPES_H 1
#define HAVE_LIBPTHREAD 1
#define HAVE_MEMORY_H 1
#define HAVE_STDINT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRINGS_H 1
#define HAVE_STRING_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_UNISTD_H 1
#define PACKAGE "SimGear"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define STDC_HEADERS 1
#define VERSION "0.3.7"
#endif
#ifdef __cplusplus
extern "C" void std::exit (int) throw (); using std::exit;

configure: exit 1

And using --plib-prefix=/usr/ did not work. It resulted in:
configure: error: unrecognized option: --plib-prefix=/usr/
Try `./configure --help' for more information.

I got PLIB 1.8.3 to compile thanks to Adam. But that didn't help
either. I think I will try to get the release version of simgear
instead of getting it from CVS. Don't think that will have any effect
though.

I'm also going to try to use --prefix=/onepath for plib and simgear.
See if that works.

Thanks for the replies!


On Wed, 10 Nov 2004 19:17:06 -, Giles Robertson
<[EMAIL PROTECTED]> wrote:
> I've found on some pseudo-POSIX Windows systems that the build only
> finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be
> what it takes; and it may be similar on OS X.
> 
> The other tactic is to specify --prefix=/fg or some other value for
> every compile; PLIB, SimGear, FGFS.
> 
> My 2 cents.
> 
> Giles Robertson
> 
> 
> 
> -Original Message-
> From: Curtis L. Olson [mailto:[EMAIL PROTECTED]
> Sent: 10 November 2004 18:59
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X
> 
> Arthur Wiebe wrote:
> 
> >Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
> >straight from CVS 2004-11-08.
> >
> >Looking in /usr/include/plib and /usr/lib/ it looks like plib is
> installed.
> >
> >The only problem I now have is when trying to configure simgear from
> >CVS (same date) I get:
> >
> >checking plib/ul.h usability... no
> >checking plib/ul.h presence... yes
> >configure: WARNING: plib/ul.h: present but cannot be compiled
> >configure: WARNING: plib/ul.h: check for missing prerequisite
> headers?
> >configure: WARNING: plib/ul.h: see the Autoconf documentation
> >configure: WARNING: plib/ul.h: section "Present But Cannot Be
> Compiled"
> >configure: WARNING: plib/ul.h: proceeding with the preprocessor's
> result
> >configure: WARNING: plib/ul.h: in the future, the compiler will take
> precedence
> >configure: WARNING: ## --
> ##
> >configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.
> ##
> >configure: WARNING: ## --
> ##
> >checking for plib/ul.h... yes
> >checking for plib 1.6.0 or newer... wrong version
> >configure: error: Install plib 1.6.0 or later first...
> >
> >That has to mean something.
> >
> >I tried changing the version in ul.h but that didn't help :). Could
> >you send me your compiled files (from /usr/lib/libplibXXX and
> >/usr/include/plib) and see if if that works? I would love to make an
> >installer package for Mac OS X which would install plib for other OSX
> >users without having to compile it.
> >
> >
> 
> The details of the configure script failure can be found in the
> config.log file.  That may shed some light on exactly what is going
> wrong.
> 
> Curt.
> 
> --
> Curtis Olsonhttp://www.flightgear.org/~curt
> HumanFIRST Program  http://www.humanfirst.umn.edu/
> FlightGear Project  http://www.flightgear.org
> Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 


-- 


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

RE: [Flightgear-devel] Re: FlightGear on Mac OS X

[Giles Robertson]

I've found on some pseudo-POSIX Windows systems that the build only
finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be
what it takes; and it may be similar on OS X.

The other tactic is to specify --prefix=/fg or some other value for
every compile; PLIB, SimGear, FGFS.

My 2 cents.

Giles Robertson

-Original Message-
From: Curtis L. Olson [mailto:[EMAIL PROTECTED] 
Sent: 10 November 2004 18:59
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: FlightGear on Mac OS X

Arthur Wiebe wrote:

>Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
>straight from CVS 2004-11-08.
>
>Looking in /usr/include/plib and /usr/lib/ it looks like plib is
installed.
>
>The only problem I now have is when trying to configure simgear from
>CVS (same date) I get:
>
>checking plib/ul.h usability... no
>checking plib/ul.h presence... yes
>configure: WARNING: plib/ul.h: present but cannot be compiled
>configure: WARNING: plib/ul.h: check for missing prerequisite
headers?
>configure: WARNING: plib/ul.h: see the Autoconf documentation
>configure: WARNING: plib/ul.h: section "Present But Cannot Be
Compiled"
>configure: WARNING: plib/ul.h: proceeding with the preprocessor's
result
>configure: WARNING: plib/ul.h: in the future, the compiler will take
precedence
>configure: WARNING: ## --
##
>configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.
##
>configure: WARNING: ## --
##
>checking for plib/ul.h... yes
>checking for plib 1.6.0 or newer... wrong version
>configure: error: Install plib 1.6.0 or later first...
>
>That has to mean something.
>
>I tried changing the version in ul.h but that didn't help :). Could
>you send me your compiled files (from /usr/lib/libplibXXX and
>/usr/include/plib) and see if if that works? I would love to make an
>installer package for Mac OS X which would install plib for other OSX
>users without having to compile it.
>  
>

The details of the configure script failure can be found in the 
config.log file.  That may shed some light on exactly what is going
wrong.

Curt.

-- 
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


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

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

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Curtis L. Olson]

Arthur Wiebe wrote:
Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
straight from CVS 2004-11-08.
Looking in /usr/include/plib and /usr/lib/ it looks like plib is installed.
The only problem I now have is when trying to configure simgear from
CVS (same date) I get:
checking plib/ul.h usability... no
checking plib/ul.h presence... yes
configure: WARNING: plib/ul.h: present but cannot be compiled
configure: WARNING: plib/ul.h: check for missing prerequisite headers?
configure: WARNING: plib/ul.h: see the Autoconf documentation
configure: WARNING: plib/ul.h: section "Present But Cannot Be Compiled"
configure: WARNING: plib/ul.h: proceeding with the preprocessor's result
configure: WARNING: plib/ul.h: in the future, the compiler will take precedence
configure: WARNING: ## -- ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.  ##
configure: WARNING: ## -- ##
checking for plib/ul.h... yes
checking for plib 1.6.0 or newer... wrong version
configure: error: Install plib 1.6.0 or later first...
That has to mean something.
I tried changing the version in ul.h but that didn't help :). Could
you send me your compiled files (from /usr/lib/libplibXXX and
/usr/include/plib) and see if if that works? I would love to make an
installer package for Mac OS X which would install plib for other OSX
users without having to compile it.
 

The details of the configure script failure can be found in the 
config.log file.  That may shed some light on exactly what is going wrong.

Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: FlightGear on Mac OS X

[Arthur Wiebe]

Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
straight from CVS 2004-11-08.

Looking in /usr/include/plib and /usr/lib/ it looks like plib is installed.

The only problem I now have is when trying to configure simgear from
CVS (same date) I get:

checking plib/ul.h usability... no
checking plib/ul.h presence... yes
configure: WARNING: plib/ul.h: present but cannot be compiled
configure: WARNING: plib/ul.h: check for missing prerequisite headers?
configure: WARNING: plib/ul.h: see the Autoconf documentation
configure: WARNING: plib/ul.h: section "Present But Cannot Be Compiled"
configure: WARNING: plib/ul.h: proceeding with the preprocessor's result
configure: WARNING: plib/ul.h: in the future, the compiler will take precedence
configure: WARNING: ## -- ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.  ##
configure: WARNING: ## -- ##
checking for plib/ul.h... yes
checking for plib 1.6.0 or newer... wrong version
configure: error: Install plib 1.6.0 or later first...

That has to mean something.

I tried changing the version in ul.h but that didn't help :). Could
you send me your compiled files (from /usr/lib/libplibXXX and
/usr/include/plib) and see if if that works? I would love to make an
installer package for Mac OS X which would install plib for other OSX
users without having to compile it.

On Wed, 10 Nov 2004 10:07:51 -0800, Adam Dershowitz
<[EMAIL PROTECTED]> wrote:
> OK,
> I now have gotten plib to compile.  No promises on the functionality.  It
> seems that jsMacOSX.cxx contained a LPVOID cast.  I can't figure out what
> this is.  It seems to be a Windows thing.  I removed that.  I hate to remove
> a cast without understanding it, but it does now compile.
> So, again, here are the diffs of the two files that I changed from the
> original to my own version.
> 
> 
> 
> diff jsMacOSX.cxx jsMacOSX_org.cxx
> 
> 17,19c17
> < //int jsJoystick::kNumDevices = 32 ;
> < int jsJoystick::kNumDevices = JS_MAX_OSX_DEVICES ;
> <
> ---
> > int jsJoystick::kNumDevices = 32 ;
> 21,22c19
> < //io_object_t jsJoystick::ioDevices[kNumDevices];
> < io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
> ---
> > io_object_t jsJoystick::ioDevices[kNumDevices];
> 132,133c129,130
> <   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
> <   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID), &hidDev);
> ---
> >   HRESULT pluginResult = (*plugin)->QueryInterface(plugin,
> >   CFUUIDGetUUIDBytes(kIOHIDDeviceInterfaceID), &(LPVOID) 
> > hidDev);
> 
> 
> 
> 
> diff js.h js_org.h
> 35,36d34
> < #define JS_MAX_OSX_DEVICES  32
> <
> 97c95
> <   static  int kNumDevices;
> ---
> >   static const int kNumDevices;
> 99,100c97
> < //  static io_object_t ioDevices[kNumDevices];
> < static io_object_t jsJoystick::ioDevices[JS_MAX_OSX_DEVICES] ;
> ---
> >   static io_object_t ioDevices[kNumDevices];
> 
> 
> So my build steps were 1)just to download with CVS.
> 2) make the above edits.
> 3) ./autogen.sh
> 4)./configure --prefix=$BUILDDIR (or whatever)
> 5) make install.
> 
> Good luck, and let me know if it works for you.
> 
> 
> 
> -- Adam
> 
> > From: Arthur Wiebe <[EMAIL PROTECTED]>
> > Reply-To: Arthur Wiebe <[EMAIL PROTECTED]>
> > Date: Wed, 10 Nov 2004 08:45:01 -0500
> > To: <[EMAIL PROTECTED]>
> > Subject: FlightGear on Mac OS X
> >
> > Hello,
> >  I just have a question. What did you do to get plib to compile? I
> > tried some things but couldn't get it to work so I just got it from
> > CVS which did work but simgear doesn't recognize it.
> > And what version of plib did you build?
> >
> > Thanks.
> > --
> > 
> 
> 


-- 


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

[Flightgear-devel] Building FlightGear on Mac OSX

[ima . sudonim]

On Nov 9th, 2004, Adam wrote:
I have been trying to build FlightGear 0.96 (CVS) on a Mac, and have 
been
using fgdev, and have followed the instructions in the FG users guide, 
as
well as the instructions included in fgdev, but I have run into a 
bunch of
problems.
Any help that anyone can offer would be greatly appreciated.
I have searched the lists and see that some others have had some of 
the same
problems, but I have not found postings of solutions.  I guess that the
instructions for building on a Mac in the users guide are somewhat out 
of
date.

I am using OSX 10.3.5 and I have Xcode 1.5 installed (gcc 3.3 and gcc
2.95.2).  The insructions say to use gcc 2.95, so I have started with 
that.
I also am using tcsh as instructed (which is no longer the Mac 
default).

First I found that by default I already had the versions of automake 
and
autoconf that the instructions say to build, so I did not do that.  
(1.6.3
and 2.53 respectively)

I had trouble getting plib to build, but, after a few changes, got it 
to
compile.
What problems did you have please? How did you fix them?
The instructions next call for building metakit, but I assume that is 
now
included in SimGear?

metakit is not needed anymore. it was replaced by something else, I'm 
afraid that I can't remember what 8-( I think it's built into simgear, 
however, and not external. Someone please correct me if I'm wrong...

Building SimGear failed with gcc 2.95.  When I switched to 3.3 it got 
much
further, but failed on testserial.  I was hoping that this is not 
critical.

So next I tried to build FlightGear itself:
./configure --prefix=$BUILDDIR --without-threads --without-x
configure: error: cannot run /bin/sh ./config.sub
What is your BUILDDIR value set to? It should be the path to the fg 
build tree (mine is
/flightgear/fgdev9.6)

I will be happy to try to help, health permitting -- November is 
shaping up to be a bad month as it's turning colder -- but please give 
some more info regarding the exact errors that you're hitting. You may 
or may not have in fact gotten past them. If plib is not built right, 
then all bets are off as to whether you'll succesfully build the rest.


I found that the reason is that config.sub does not exist.
I have config.sub in ./src/FlightGear, ./src/plib and ./src/SimGear
I didn't check all of them but config.sub in src/FlightGear is a link 
to:

lrwxrwxrwx  1 ima  staff  34 19 Jun  2003 src/flightgear/config.sub -> 
/usr/share/automake-1.6/config.sub

are you sure you've got automake installed right? This is NOT something 
that seems to be touched on every build... My src/FlightGear file has 
the following timestamp inside it:

timestamp='2002-07-03'
Shouldn't
autogen.sh create this file?  Did I do something wrong?
(I see that someone else had the same problem and posted to the mailing
list, but I could not find a response).
So, where I think I stand is:  I have plib, I think that I have 
SimGear?  I
have downloaded and installed OpenAL and I can't get FG itself to even 
start
to compile.

Thanks,
-- Adam

Here are my build scripts (I build from the command line, I think that 
others on the list have FG building from XCode but I haven't done this:

 cat makeplib.sh makesg.sh makefg.sh
 cd $BUILDDIR/src/plib
 ./autogen.sh
 ./configure --prefix=$BUILDDIR
 make install
 cd $BUILDDIR/src/SimGear
 ./autogen.sh
 ./configure --prefix=$BUILDDIR
 make install
 cd $BUILDDIR/src/FlightGear
 ./autogen.sh
 ./configure --prefix=$BUILDDIR --with-threads --without-x
 make install
echo "'make install' done"
My GCC version is:
gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

I am using mac os x 10.3.6, but did build with 10.5 in the past.
I last built plib, simgear and flightgear from CVS on 11/5/04 and had 
no problems.

I am using automake 1.6.3 and autoconf 2.57
Hope this helps.
Welcome to the project, FlightGear is a great Mac OS X compatible 
flight sim.  I haven't used X Plane in years even. 8-) This is a great 
list, with a lot of skilled and helpful people on it...

Ima
PS -- if you use .sh scripts with tcsh, you'll need to run child 
scripts via the 'source' command in order to properly pass the 
environment (including BUILDDIR to the child processes)

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

Re: [Flightgear-devel] apr mode

[Roy Vegard Ovesen]

On Wednesday 10 November 2004 15:09, Amit Gulati wrote:
> Does the autopilot "apr" mode work in version 0.9.6? If yes, then using
> which aircrafts?

If you are talking about the thin autopilot panel with buttons for WL, HDG, 
NAV, APR, ALT, then no! This instrument used to be tied to the old hardcoded 
autopilot that was rewritten almost a year ago now. If you are talking about 
the autopilot GUI dialog available from the Autopilot menu, then no, 
again! :-( There is no explicit APR mode in the autopilot dialog, but you 
could activate the NAV1 CDI Course and the NAV1 Glideslope. Infortunetly  the 
NAV1 CDI Course mode does not seem to work.

The autopilot dialog is tied to the generic autopilot configuration that is 
available in all aircraft, unless they use a custom autopilot configuration. 
Since there are so many different aircraft in FligtGear it is close to 
impossible to design a generic autopilot that would work for all aircraft.

Please try the autopilot in the default Cessna, it should have a working apr 
mode. But you have to know how to use it. A link to the pilot's guide was 
posted on the user list very recently.

-- 
Roy Vegard Ovesen

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

Re: [Flightgear-devel] Beech 99

[Roy Vegard Ovesen]

On Wednesday 10 November 2004 13:01, Antonio Pennino wrote:
> > I think you should remove the ADF radio panel, since there is no
> > instrument to display the adf bearing. Alternatively add an adf bearing
> > indicator.
>
> I use the 0.9.6 win32 binary. How i make it?

This question forces me to rethink my previous assumption that you were the 
maintainer of the Beach 99.

If you know nothing about panels, a good place to start would be 
README.xmlpanel in the Docs directory. It is also very helpful to look at 
existing panel configurations.

-- 
Roy Vegard Ovesen

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

Re: [Flightgear-devel] Beech 99

[Antonio Pennino]

From:   "Antonio Pennino" <[EMAIL PROTECTED]>
Organization:   Nocera Informatica
To: FlightGear developers discussions 
<[EMAIL PROTECTED]>
Date sent:  Wed, 10 Nov 2004 13:01:35 +0100
Subject:Re: [Flightgear-devel] Beech 99
Priority:   normal
Send reply to:  FlightGear developers discussions 
<[EMAIL PROTECTED]>



> i have also use the 'b' key. Nothing.

solved! It is need press the key and NOT release it!!



Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : [EMAIL PROTECTED]



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

[Flightgear-devel] apr mode

[Amit Gulati]

Does the autopilot "apr" mode work in version 0.9.6? If yes, then using 
which aircrafts?

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

[Flightgear-devel] Re: Beech 99

[Melchior FRANZ]

* Antonio Pennino -- Wednesday 10 November 2004 11:08:
> please verify the brakes 

There was a bug that is now fixed in cvs. You can make the changes yourself:
In file $FG_ROOT/Aircraft/beech99/Instruments/b99-brakes.xml replace all
occurrences of "parking-brake" by "brake-parking". (That's at two places.)

Everything else brake related is correct and works here.

m.

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

Re: [Flightgear-devel] Beech 99

[Antonio Pennino]

From:   Roy Vegard Ovesen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject:Re: [Flightgear-devel] Beech 99
Date sent:  Wed, 10 Nov 2004 12:06:21 +0100
Send reply to:  FlightGear developers discussions 
<[EMAIL PROTECTED]>



> Wheel brakes are working as expected. The "BRAKES" indicator on the panel is 
> not working.

i have also use the 'b' key. Nothing.
 
> I think you should remove the ADF radio panel, since there is no instrument 
> to 
> display the adf bearing. Alternatively add an adf bearing indicator.

I use the 0.9.6 win32 binary. How i make it?
 
 




Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : [EMAIL PROTECTED]



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

Re: [Flightgear-devel] Beech 99

[Roy Vegard Ovesen]

On Wednesday 10 November 2004 11:08, Antonio Pennino wrote:
> please verify the brakes and the dimension and visual
> definition of the cockpit at the 800x600 resolution.

Wheel brakes are working as expected. The "BRAKES" indicator on the panel is 
not working.

I think you should remove the ADF radio panel, since there is no instrument to 
display the adf bearing. Alternatively add an adf bearing indicator.

Also (if you are using the latest CVS version) I think you should consider to 
add a second airspeed indicator and turn indicator module. I see that those 
two instruments are visible from the copilot's panel. Now, I'm guessing that 
the the airspeed indicator on both sides are tied to the same property, so 
both fail at the same time. If you add a second airspeed indicator module, 
you can make the two airspeed indicators independent of eachother. This also 
applies to the turn indicator.

-- 
Roy Vegard Ovesen

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

[Flightgear-devel] Beech 99

[Antonio Pennino]

please verify the brakes and the dimension and visual 
definition of the cockpit at the 800x600 resolution.




Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : [EMAIL PROTECTED]



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

RE: [Flightgear-devel] Seafire and Spitfire engine startup

[Vivian Meazza]

Paul Surgeon wrote:

> On Monday, 8 November 2004 11:13, Vivian Meazza wrote:
> > Could you use the properties browser to make sure
> all switches/fuel cocks
> > are in the right position, and confirm that the
> Coffman starter is indexing
> > correctly? You are using the starter button and not
> the adjacent fuel gauge
> > button (I'm sure you are)? The engine will do a
> windmill start if you
> > switch the magnetos to 'on' while the engine is
> rotating above about
> > 500rpm.
> 
> I got the windmill start to work but it did something
> a bit odd.
> The magnetos were both on but I had to click on one of
> them and only then would the engine start running. The
> switch position were still the same before and after
> (on position) but clicking on one of them "did
> something".

That is odd - they should begin in the 'off' (down) position. Flipping one
to 'on' should be enough to do a windmill start. Could you look at that one
again?

> 
> However the aircraft cannot be started on the ground
> using a GLUT build. Rebuilding with SDL fixed the
> problem so it looks like Melchior may be right.
> When I fired the starter the property stayed "true"
> for as long as I held the key down.

I'm sure Melchior is right - I think he uses the Spitfire more than I.

> 
> Oddly enough the 172 starts just fine using glut.
> 

I don't think you can read too much into this - the Spitfire uses some
complex NASAL code to achieve the start routines. I don't think this is the
case for the 172.

Anyway, I'm glad that you have got it to work, even if only partially.

Vivian 



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