Yes I found out quickly that locate does not stay up to date. But it
did find everything. I think the datebase rebuilds daily or something.

But I decided to try to build simgear again (from CVS) and it seems in
a file called matlib.cxx in material it contains the following line:

#include <GL/gl.h>

and it needs to be changed to 
#include <OpenGL/gl.h>
in order to build on OSX. At least for me.
Previously I had it using the X11 supplied GLUT headers but I didn't
this time which is how I noticed this.

It's the same story but a little different in clouds3d/glut_shapes.c line 54

#include <GL/glu.h>
shoud be

#include <OpenGL/glu.h>

Same thing in glut_shapes.h line 17
SkyMaterial.hpp in line 36

I had to make the same two changes on many different files in order to
get simgear to compile without using Apple's X11.
I'll see if I can make a patch.

I'll now try flightgear again. (I've already redone PLIB)

On Sat, 13 Nov 2004 15:31:38 +0100, Boris Koenig <[EMAIL PROTECTED]> wrote:
> Arthur Wiebe wrote:
> > Another way to do it which is what I did was use the following command:
> > locate plibfnt
> >
> > It returned:
> > /fgfs/lib/libplibfnt.a
> > /Users/myuser/FlightGear/plib/src/fnt/libplibfnt.a
> "(s)locate" doesn't really "browse" your file system, as 'find' would
> do - rather, (s)locate runs a query against a simple database,
> if that database is not in sync with your local file system, it can
> very well happen, that (s)locate returns results that don't resemble
> the actual situation on your hard disk, hence it is recommended that
> you either use 'find' directly or simply run a 'updatedb' in order to
> synchronize the database with your file system - which may take quite
> a while, depending on your file system structure.
> Also, you won't have to do a manual search for any references of 'load',
> you can easily use 'grep' for that, too - something like:
>         nm library.a | grep -i font | grep -i load | less
> would return all results that contain a "font" AND a "load"
> reference, limiting the search in such a manner would probably
> also make the piping to less superfluous.
> Using some clever sed'ing could even take care of automatically
> comparing object file exports and library exports.
> ---------
> Boris
> _______________________________________________
> Flightgear-devel mailing list
> 2f585eeea02e2c79d7b1d8c4963bae2d


Flightgear-devel mailing list

Reply via email to