opengc-devel — Developer's discussion list

Re: [Opengc-devel] Building OpenGC

[Damion S. <dam...@ho...>]

Hi,

You should be building Freetype 2.x and FTGL (I believe v1.4 just came out).
Also, as a reminder, please use CMake and _not_ the included
configure/makefile scripts as these are extremely out of date. It is a
little surprising that you're having problems with Freetype - I've found it
to be quite stable. Also - this is not yet listed on the web site - you will
need to download and build FLTK (http://www.fltk.org) which we're using in
Glut emulation mode.

If you get past building the external libraries and have trouble building
OpenGC itself, please let me know.

Cheers,
-Damion-

----- Original Message -----
From: "Peter Holt" <ph...@ih...>
To: <ope...@li...>
Sent: Thursday, October 31, 2002 10:00 AM
Subject: [Opengc-devel] Building OpenGC


> I've been trying to build OpenGC with gcc under cygwin on a Windows XP
system and I haven't been able to get past building the various libraries.
I had no problem with PLib or zlib but the fonts libraries have me stopped.
>
> Should I be using freetype and gltt, or freetype2 and FTGL?  I've had
problems with both.  At least finding out which set of problems I should be
trying to solve would be a start.
>
> Peter
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>

[Opengc-devel] Building OpenGC

[Peter H. <ph...@ih...>]

I've been trying to build OpenGC with gcc under cygwin on a Windows XP system and I haven't been able to get past building the various libraries.  I had no problem with PLib or zlib but the fonts libraries have me stopped.

Should I be using freetype and gltt, or freetype2 and FTGL?  I've had problems with both.  At least finding out which set of problems I should be trying to solve would be a start.

Peter

Re: [Opengc-devel] opengc 0.3 under windows xp

[Damion S. <dam...@ho...>]

Under Windows, capitalization in directory and file names doesn't =
matter. So arial.ttf =3D ArIaL.tTf =3D etc. I'll cut another release =
tonight with the version of the suspect DLL that Visual Studio uses, on =
the off chance that it's causing trouble.

-Damion-
  ----- Original Message -----=20
  From: Rick Marsico=20
  To: 'Damion Shelton'=20
  Sent: Tuesday, October 29, 2002 12:24 PM
  Subject: RE: [Opengc-devel] opengc 0.3 under windows xp


  Yes, it's there but I'm wondering if the case is causing a problem.  I =
see ARIAL.TTF in the Fonts directory.



  Rick

Re: [Opengc-devel] opengc 0.3 under windows xp

[Damion S. <dam...@ho...>]

Forgot to hit "reply all"...
--------

Hmmm....

I should probably package that DLL with the download - you're not the first
person to run into problems with it. But, if OpenGC is able to start at all,
that's probably not the problem. Did you verify that the font path is
correct (by actually checking for arial.ttf at the location specified by
opengc.ini). The hang that you're describing suggests that the font path is
not correct.

On my Win2000 machine, the font path is C:/WinNT/Fonts/ - I don't have an XP
machine available to look at at the moment. Let me know if you discover
anything.

Cheers,
-Damion-

----- Original Message -----
From: Rick Marsico
To: ope...@li...
Sent: Tuesday, October 29, 2002 9:04 AM
Subject: [Opengc-devel] opengc 0.3 under windows xp


Any advice on getting this to work?  First time around I received a message
saying MSVCP70.DLL was missing.  I downloaded and installed version
7.0.9064.0 of the dll (it's the only one I could find).  Now I see the
following two messages in a dos box "ogcAppObject constructed" and
"ogcFontManger constructed".  Things hang right there with the processor
pegged at 100%.

My OpenGC.ini follows.

Rick


# OpenGC - The Open Glass Cockpit Project

# This is a sample initialization file
# It will probably _NOT_ work on your system without changing paths

#--------BASE INITIALIZATION
# These attributes must always be present, in order, and valid

NAV DATABASE PATH
C:/temp_opengc/navbase/

FONT PATH
C:/WINDOWS/Fonts/

DATA SOURCE
FSUIPC
#X-Plane
#Flightgear

RENDER WINDOW
0 0 1024 768

#--------EXTRA INITIALIZATION
# May or may not be applicable

# Flightgear network setup
NETWORK
5800 5700
192.168.2.10

# Root definition for Flightgear
OGCROOT
C:/temp_opengc/opengc

#--------GAUGE INITIALIZATION
# An arbitray number may be present

NEWGAUGE
Boeing777PFD
10 10 0.75 0.75
ENDGAUGE

NEWGAUGE
Boeing737EICAS
160 10 0.75 0.75
ENDGAUGE

## Legal gauge names listed below
# Boeing777PFD
# Boeing777EICAS
# BoeingNav
# Boeing737PFD
# Boeing737EICAS
# Boeing737NAV
# Boeing737AnalogFlaps
# Boeing737VerticalSpeedDigital
# BoeingAFDS
# Keypad

Re: [Opengc-devel] flightgear 0.8.0 and opengc

[Damion S. <dam...@ho...>]

Forgot to hit "reply all"...
--------

Yes - as I mentioned earlier it works fine using a windows machine running
Flightgear 0.8 and a windows machine running the CVS OpenGC. You might
consider emailing the Flightgear devel list to see if this an issue with
Flightgear on a linux machine.

-Damion-

----- Original Message -----
From: "Rick Marsico" <ri...@cc...>
To: <ope...@li...>
Sent: Monday, October 28, 2002 10:24 AM
Subject: [Opengc-devel] flightgear 0.8.0 and opengc


> Is anyone out there successfully using flightgear 0.8.0 with any version
> of opengc?  I can't get past the socket error I'm seeing in fgfs.  I
> have successfully used other network options available with 0.8.0 so the
> problem appears specific to the --opengc  option.  In the archives, all
> I see are references to the --native option but not to --opengc.
>
> Rick
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>

Re: [Opengc-devel] OpenGC 0.3

[Damion S. <dam...@ho...>]

Forgot to hit "reply all"...
--------

Hi,

The case issue is something that I need to clear up - there wasn't any
standard enforced for a while, and then I made a few changes but didn't
apply everything consistently. In any case, it's (as you noticed) somewhat
screwy for the time being.

Regarding the crashes: the BoeingNav (or NAV) gauge should work fairly
well - it is older and does not attempt to render geographic data. The 737
Nav gauge renders geographic data but is still under development and
probably should not be counted on to work reliably yet. I'm not the author
of this gauge, so I can't comment on its status. The PFD's and EICAS's
should work without crashing though - if you have problems with them, let me
know, since I probably need to put some debugging time in.

Cheers,
-Damion-

----- Original Message -----
From: "Peter Holt" <ph...@ih...>
To: <ope...@li...>
Sent: Tuesday, October 29, 2002 9:02 AM
Subject: [Opengc-devel] OpenGC 0.3


> I've solved my problem with the nav gauges.  It was a case problem.  I
think what confused me was that in the list of legal gauge names in
opengc.ini BoeingNav is listed instead of BoeingNAV.
>
> I'm still having the frequent crashes, though.
>
> Peter
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>

[Opengc-devel] opengc 0.3 under windows xp

[Rick M. <rjm...@ys...>]

Any advice on getting this to work?  First time around I received a
message saying MSVCP70.DLL was missing.  I downloaded and installed
version 7.0.9064.0 of the dll (it's the only one I could find).  Now I
see the following two messages in a dos box "ogcAppObject constructed"
and "ogcFontManger constructed".  Things hang right there with the
processor pegged at 100%.

 

My OpenGC.ini follows.

 

Rick

 

 

# OpenGC - The Open Glass Cockpit Project

 

# This is a sample initialization file

# It will probably _NOT_ work on your system without changing paths

 

#--------BASE INITIALIZATION

# These attributes must always be present, in order, and valid

 

NAV DATABASE PATH

C:/temp_opengc/navbase/

 

FONT PATH

C:/WINDOWS/Fonts/

 

DATA SOURCE

FSUIPC

#X-Plane

#Flightgear

 

RENDER WINDOW

0 0 1024 768

 

#--------EXTRA INITIALIZATION

# May or may not be applicable

 

# Flightgear network setup

NETWORK

5800 5700

192.168.2.10

 

# Root definition for Flightgear

OGCROOT

C:/temp_opengc/opengc

 

#--------GAUGE INITIALIZATION

# An arbitray number may be present

 

NEWGAUGE

Boeing777PFD

10 10 0.75 0.75

ENDGAUGE

 

NEWGAUGE

Boeing737EICAS

160 10 0.75 0.75

ENDGAUGE

 

## Legal gauge names listed below

# Boeing777PFD

# Boeing777EICAS

# BoeingNav

# Boeing737PFD

# Boeing737EICAS

# Boeing737NAV

# Boeing737AnalogFlaps

# Boeing737VerticalSpeedDigital

# BoeingAFDS

# Keypad

[Opengc-devel] OpenGC 0.3

[Peter H. <ph...@ih...>]

I've solved my problem with the nav gauges.  It was a case problem.  I think what confused me was that in the list of legal gauge names in opengc.ini BoeingNav is listed instead of BoeingNAV.

I'm still having the frequent crashes, though.

Peter

[Opengc-devel] OpenGC 0.3

[Peter H. <ph...@ih...>]

I've been having a few problems with opengc 0.3.  I'm running under Windows XP Pro.  I can't get either of the NAV gauges to appear.  If I specify BoeingNav or Boeing737NAV in the ini file, I just get a blank window.  Looking at the messages in the text window, it appears that the gauges aren't being constructed.  All other gauges appear correctly.

The program also frequently crashes with an 'abnormal program termination' runtime error.

Peter

[Opengc-devel] flightgear 0.8.0 and opengc

[Rick M. <ri...@cc...>]

Is anyone out there successfully using flightgear 0.8.0 with any version 
of opengc?  I can't get past the socket error I'm seeing in fgfs.  I 
have successfully used other network options available with 0.8.0 so the 
problem appears specific to the --opengc  option.  In the archives, all 
I see are references to the --native option but not to --opengc.

Rick

Re: [Opengc-devel] Flightgear status(!) & request for help (resend)

[Gene B. <ge...@de...>]

> Hmmm.... I'm not really familiar with what's involved with worrying about
> that sort of thing. Since you mentioned "byte alignment", I ran a search and
> it appears that Windows assumes that all data structures are multiples of 8
> bytes. 696 is a multiple of 8, while 692 (which is the true size of the
> struct, based on the number of vars and their sizes) is not. So, is it
> correct to assume that Windows is tacking on an extra four bytes to maintain
> the x8 rule?
>
This is what I would suspect, yes.  I think if you set the Linux compiler
to do word alignment, it should fix it.

g.

Re: [Opengc-devel] Flightgear status(!) & request for help (resend)

[Damion S. <dam...@ho...>]

Hmmm.... I'm not really familiar with what's involved with worrying about
that sort of thing. Since you mentioned "byte alignment", I ran a search and
it appears that Windows assumes that all data structures are multiples of 8
bytes. 696 is a multiple of 8, while 692 (which is the true size of the
struct, based on the number of vars and their sizes) is not. So, is it
correct to assume that Windows is tacking on an extra four bytes to maintain
the x8 rule?

Thanks,
-Damion-

----- Original Message -----
From: "Gene Buckle" <ge...@de...>
To: "Damion Shelton" <dam...@ho...>
Cc: <ope...@li...>
Sent: Friday, October 25, 2002 1:15 PM
Subject: Re: [Opengc-devel] Flightgear status(!) & request for help (resend)


> > BUT... here's where the help request comes in. It looks like Windows and
> > Linux are handling object sizing differently. Under Windows,
> > sizeof(ogcFGData) = 696 while on Linux sizeof(ogcFGData) = 692. I'm not
sure
>
>
> Make sure the byte alignment is the same on both systems.  I run into this
> frequently when working with FPC (pascal) projects that are cross
> platform.
>
> g.
>

Re: [Opengc-devel] Flightgear status(!) & request for help (resend)

[Gene B. <ge...@de...>]

> BUT... here's where the help request comes in. It looks like Windows and
> Linux are handling object sizing differently. Under Windows,
> sizeof(ogcFGData) = 696 while on Linux sizeof(ogcFGData) = 692. I'm not sure


Make sure the byte alignment is the same on both systems.  I run into this
frequently when working with FPC (pascal) projects that are cross
platform.

g.

[Opengc-devel] Flightgear status(!) & request for help (resend)

[Damion S. <dam...@ho...>]

The original version of this message bounced, so I'm re-sending.
----------

> Is there any version of the prebuilt windows OpenGC.exe that will
> communicate with flightgear that I can get my hands on?

Actually, as it so happens I rewrote the FlightGear data source last night
using Plib and it works great. This was much simpler than I thought; since
Plib is cross platform, the FlightGear data source now works under both
Linux (see below) and Windows. I had to replace the FG packet header with
the one from the FlightGear 0.80 repository but other than that there
weren't any unexpected problems. So far I've tested the system with both
FlightGear and OpenGC running on Windows XP machines.

BUT... here's where the help request comes in. It looks like Windows and
Linux are handling object sizing differently. Under Windows,
sizeof(ogcFGData) = 696 while on Linux sizeof(ogcFGData) = 692. I'm not sure
where the extra 4 bytes are going. This makes things awkward since the comms
built into flightgear dump this data structure out as the network packet,
and the size differences are making it impossible to cast the memory block
as the correct pointer type when mixing different machines on a network.

Any people with cross-platform network experience have advice? As of now,
things work correctly when both the source and target machines use the same
OS (or at least I'm assuming the Linux side works - it compiles and receives
packets from my Windows machine correctly, but segfaults on the cast
operation - I don't have a second Linux machine to play with). It seems like
this might be a buffer offset issue; perhaps by lopping 4 bytes off of one
end of the buffer I can solve the problem.

Once this issue is ironed out, the only remaining piece of "disabled" code
is John W's FMC. Re-enabling FMC is a more involved process, since it
involves some fundamental changes to the DataSource base class; this why
I've started using macros in the code - in the future, they will define
"Set" functions for variables that can be written out over the network. I'm
a little up in the air about how this will be pulled off at this point. A
common engineering trick would be to define a Current state/Next state pair,
with the current state being read only and the next state being writable
(but a limited subset of the current state). If anyone has a particular
preference about how this should be organized, let me know.

A final note: if you download the updated CVS to acquire Flightgear support,
please be aware that I changed the opengc.ini keywork for the FlightGear
data source to "FlightGear" from "Flightgear" to agree with the
capitalization from the official web site. This interface should be
considered somewhat experimental until the packet size issues are resolved.
Instructions on how to start Flightgear with opengc support can be found in
the opengc.txt file in the CVS repository. The short version is to add the
following switch to the command line when starting flightgear:

--opengc=socket,out,24,xxx.xxx.xxx.xxx,5800,udp

replacing the x's with the target IP address. For example:

--opengc=socket,out,24,192.168.1.255,5800,udp

to broadcast to all machines on the 192.168.1 network.

Happy flying...
-Damion-

[Opengc-devel] socket error with FlightGear 0.80

[Rick M. <rjm...@ys...>]

I hope the following error is due to my ignorance of Linux and not a 

problem with FlightGear 0.80.  What I am seeing under RedHat 7.3 when 

using the --opengc ... option are the following streaming (repeated)
errors:

 

Error writing data.

Error writing to socket: 5800

 

I see this error with two unique installations of FlightGear/redhat.

 

Any thoughts as to what may be causing this?  (I am able to use opengc
with x-plane over the same network.)

 

Rick

 

[Opengc-devel] Re: Impressive!

[Damion S. <dam...@ho...>]

Hi,

> I'm curious as to why the bi-directional link to x-plane.  Should the
> opengc flight controls and fmc settings (e.g., Page Up/Page Down,
> heading, altitude, etc...) be functional with xp?

Nope. I suppose my explanation wasn't great: the last checkbox _does not_
require bidirectional comms, and is therefore suitable for use with OpenGC,
which does not yet support bidirectional comms. The other boxes appear to
require handshaking between the client and server. Until I get a chance to
update the data source and FMC code, OpenGC is receive-only.

> They do nothing to my
> networked xp environment.  I do have the last checkbox selected as
> instructed below.

Ok. Did you fill in the network info next to it?

> Also, I gave the windows executable a go under Windows XP. Upon
> executing OpenGC.exe I see two messages in a dos box.  They are
> "ogcAppObject constructed" and "ogcFontManager constructed" and the
> application hangs as the processor is pegged at 100%.  Can the app run
> under windows xp?

This is consistent with the opengc.ini file not being set up correctly.
Check to make sure that all of the paths are correct. The exe version of
OpenGC was built using Visual Studio.NET under XP so there shouldn't be any
fundamental problems.

-Damion-

Re: [Opengc-devel] Re: getting closer!

[Damion S. <dam...@ho...>]

Yes, using CVS you can checkout an earlier version of the code by date
(you'd probably need to back up to pre-July). Some things to be aware of if
you do this:

1) No 737 gauges
2) You'll need to rebuild with the configure and makefile scripts, not CMake
3) You'll need to build with Glut and not FLTK
4) I can't offer assistance with the build since I've never built using
anything but CMake

Personally, I'd recommend waiting until I have a chance to integrate the
existing Flightgear code into the CMake build; all of the code is still
present (and as far as I know, functional). However, I have not heard from
the person who wrote the flightgear code in some time so I have no idea what
the status of flightgear support under OpenGC is at the moment...

-Damion-

----- Original Message -----
From: "Rick Marsico" <ri...@cc...>
To: "'Damion Shelton'" <dam...@ho...>
Sent: Thursday, October 24, 2002 8:39 AM
Subject: RE: [Opengc-devel] Re: getting closer!


> X-Plane only! I didn't realize this. Is there any way I can get my hands
> on a prior version that is flightgear compatible?
>
> Rick

[Opengc-devel] OpenGC build status

[Damion S. <dam...@ho...>]

Hi,

A quick note that both Windows and Linux builds are now working. There's an
issue with the geo_pos.h file defining a round(double) function works fine
under Redhat Linux and Visual Studio .NET but not on Mandrake Linux. I'm
going to assume that the majority rules, and there's something wrong with
Mandrake... more exploration is needed.

Another note for Windows users: use FLTK 1.1 and _not_ 1.1.1; there's a link
error with the latter that I haven't been able to debug. If you're
downloading a fresh copy, you may need to directly access one of the FLTK
ftp servers rather than using their link button.

A few things I jotted down when getting the Linux build to work:

1) Problem noted with round() function

2) added geo_pos.h include to latlongc.cpp

3) numerous capitalization corrections - Windows users, please be aware that
myFilename.cpp, MyFilename.cpp, and MYFILENAME.CPP are all different files
on Unix platforms and includes will not work correctly unless the
capitalization is correct.

4) I changed the case of uppercase filenames in /Math to lowercase to match
the other files and fix problems related to (3) above. Note that the
uppercase versions are no longer in the repository - if anyone has made
changes to these and hasn't updated recently, be careful when you do so that
you don't lose your work. In the future, I'd suggest that either camel
hump - myFileName.cpp - or lowercase, myfilename.cpp - style be used. All
files that are prefaced with ogc should use camel hump: i.e. ogcDataSource.h

5) I'm toying with the idea of switching all includes defined as
</Foo/File.h> to "File.h". The former is system path form, while the latter
is local form. I had to correct many case problems here as well, and the
addition of the /Foo path is not neccessary since the CMakeLists.txt file
sets up include directories for the compiler. Therefore, if any directories
change name or files are moved, it's not neccessary to modify every file
that includes the desired target. I started the <Foo/File.h> convention to
begin with, but I think I'll reverse my position and encourage the straight
"File.h" form in the future unless anyone has a strong argument to the
contrary.

I'll post updated build instructions over the next several days along with a
binary Linux release.

Cheers,
-Damion-

[Opengc-devel] Re: getting closer!

[Damion S. <dam...@ho...>]

Ok, you're in the home stretch! This is easy to fix:

1) Make sure the contents of the nav zip file from Sourceforge are unzipped
into /usr/local/navbase (or NavBase, or whatever)
2) _Don't_ unzip any of the .gz files that are present in
/usr/local/navbase - they're supposed to be zipped
3) Here's the part I think is causing the error: the path name has to have a
trailing "/". So your path would look like:

/usr/local/NavBase/

A smarter version of the ini code would check for a trailing / and add one
if it's missing. I should probably make that a priority. Let me know if
adding the / fixes the problem.

As a reminder, only the X-Plane data source works under Linux with the
current build setup. I've disabled the flightgear code (temporarily) because
it relies on Unix-specific networking and is not well integrated with CMake.
There are X-plane configuration instructions included with the exe
download - I don't think I've checked them into the CVS yet.

-Damion-

----- Original Message -----
From: "Rick Marsico" <ri...@cc...>
To: "Damion Shelton" <dam...@ho...>
Cc: <ri...@cc...>
Sent: Wednesday, October 23, 2002 4:35 PM
Subject: getting closer!


> Damion,
>
> Uncommenting the "round" function allowed me to achieve a successful
> build!  I proceeded to set up the required opengc.ini.  I also moved the
> nav database to /usr/local/NavBase.  In opengc.ini I set the NAV
> DATABASE PATH to /usr/local/NavBase.
>
> Upon executing OpenGC, things appear normal until I see the messages:
>
> Initing nav database
> /usr/local/NavBasedefault.nav
> file read error
>
> Things hang at this point.
>
> I tried renaming the NavBase directory to NavBasedefault.nav.  These are
> the resulting messages:
>
> Initing nav database
> /usr/loca/NavBasedefault.nav
> initing ils
>
> Rather than just hanging, the application then terminates.
>
> Just to see what would happen I also tried the .zip version of the nav
> database.  Same results.
>
> Rick
>
>
>
>

Re: [Opengc-devel] building opengc under redhat 7.3

[Damion S. <dam...@ho...>]

Hi,

I think I've found you're problem There's a function called "round" in
geo_pos.h (under Math) which on my Mandrake box was conflicting with a
stdlib implementation of a function with the same name. I commented it out,
and it worked fine. On my Windows machine, this function is apparently not
defined by default and I'm assuming something similar is happening on your
Redhat system. This error prevents latlongc.o from being generated, which is
what you were seeing.

Try removing the comment in front of the declaration of round geo_pos.h - if
this works on your system and my Windows machine, I'll assume there's a
problem with Mandrake and concoct a fix (maybe renaming the round function
to ogcRound or something).

-Damion-

----- Original Message -----
From: "Rick Marsico" <ri...@cc...>
To: <da...@op...>
Sent: Wednesday, October 23, 2002 12:52 PM
Subject: Re: [Opengc-devel] building opengc under redhat 7.3


> Damion,
>
> I'm in the process of re-downloading now.  When in ccmake, I specify the
> build directory, correct?  Perhaps this is where I'm getting things
> confused?
>
> Rick
>
> Damion Shelton wrote:
>
> > Hi,
> >
> > I've also read your more recent message.... using CMake is the correct
> > thing to do. The make and configure scripts in the CVS repository are
> > no longer functional, as you discovered.
> >
> >> Prior to these statements, I see a number of warning statements
> >> ending with "does not give a valid preprocessing token" (e.g.,
> >> ../../Source/DataSources/ogcDataSource.h:422:3: warning: pasting "->"
> >> and "Wind_Velocity" does not givie a valid preprocessing token).
> >
> >
> > I'm not sure why these warnings are appearing, but they don't indicate
> > a problem. They show up on my Linux system as well, although not under
> > Windows. I'll have to do some reading to figure out what's happening
> > (they are caused by my use of macros in the ogcDataSource.h file, but
> > I'm not sure why - the syntax is legal and the code compiles as
> > expected).
> >
> > As to your current problem with latlongc.o not being available....
> > that's pretty strange. When was your CVS last updated? One thing I
> > might suggest is to completely delete both your current CVS and build
> > directories, download a fresh copy, and try rebuilding from scratch.
> > It's possible something got messed up when you used the configure
> > scripts.
> >
> > Are you using separate build and source directories? I.e., your source
> > directory is named ~/opengc and your build directory is ~/opengcbin
> > (or something similar)? If not, I'd suggest doing this under the
> > assumption that the makefiles present in the repository could be
> > interfering with the makefiles generated by CMake. Incidentally, the
> > executable is named OpenGC (note capitalization), and should appear in
> > the root of the build directory (i.e. ~/opengcbin/OpenGC ).
> >
> > Let me know how it goes - I'd like to make sure I'm not the only
> > person who can build OpenGC!
> >
> > -Damion-
> >
> > _________________________________________________________________
> > Internet access plans that fit your lifestyle -- join MSN.
> > http://resourcecenter.msn.com/access/plans/default.asp
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future of Java(TM)
> > technology. Join the Java Community Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> >
> > _______________________________________________
> > Opengc-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opengc-devel
>

Re: [Opengc-devel] Addition to OpenGC?

[Damion S. <dam...@ho...>]

Sure, how complicated are we talking (relative to the 777 PFD for example)?

-Damion-

----- Original Message ----- 
From: "Gene Buckle" <ge...@de...>
To: <ope...@li...>
Sent: Wednesday, October 23, 2002 4:54 PM
Subject: [Opengc-devel] Addition to OpenGC?


> Would anyone be interested in adding a HUD mode to OpenGC if I were to
> supply the documentation on the symbology layout?
> 
> thanks!
> 
> g.

Re: [Opengc-devel] building opengc under redhat 7.3

[Damion S. <dam...@ho...>]

Hi,

That's correct, depending on what you mean... I'll describe the "complete"
process starting with a fresh download of the CVS:

1) Assuming opengc is in ~/opengc, start in ~
2) mkdir ./opengcbin
3) cd opengcbin
4) ccmake ../opengc
5) hit "c" (configure) until the "g" (generate) option appears
6) hit "g", CMake will build the makefiles and drop back to the shell
7) make

You may also need to select Fltk 1.1 rather than 1.0, depending on what
CMake finds. You want 1.1 "on" and 1.0 "off". After changing this you will
need to hit "c" again. Note that this procedure presumes plib, fltk, ftgl,
and freetype to already be built and installed (although it sounds like you
have done this since your not getting include errors).

So, to answer your original question, the build directory is selected
implicitly, since it occurs wherever you run ccmake. You can run ccmake from
within the opengc cvs directory, but I recommend against this since it mixes
executable code with the source and makes CVS management more complicated.

Cheers,
-Damion-

----- Original Message -----
From: "Rick Marsico" <ri...@cc...>
To: <da...@op...>
Sent: Wednesday, October 23, 2002 12:52 PM
Subject: Re: [Opengc-devel] building opengc under redhat 7.3


> Damion,
>
> I'm in the process of re-downloading now.  When in ccmake, I specify the
> build directory, correct?  Perhaps this is where I'm getting things
> confused?
>
> Rick

[Opengc-devel] Addition to OpenGC?

[Gene B. <ge...@de...>]

Would anyone be interested in adding a HUD mode to OpenGC if I were to
supply the documentation on the symbology layout?

thanks!

g.

Re: [Opengc-devel] building opengc under redhat 7.3

[Damion S. <dam...@ho...>]

Hi,

I've also read your more recent message.... using CMake is the correct thing 
to do. The make and configure scripts in the CVS repository are no longer 
functional, as you discovered.

>Prior to these statements, I see a number of warning statements ending with 
>"does not give a valid preprocessing token" (e.g., 
>../../Source/DataSources/ogcDataSource.h:422:3: warning: pasting "->" and 
>"Wind_Velocity" does not givie a valid preprocessing token).

I'm not sure why these warnings are appearing, but they don't indicate a 
problem. They show up on my Linux system as well, although not under 
Windows. I'll have to do some reading to figure out what's happening (they 
are caused by my use of macros in the ogcDataSource.h file, but I'm not sure 
why - the syntax is legal and the code compiles as expected).

As to your current problem with latlongc.o not being available.... that's 
pretty strange. When was your CVS last updated? One thing I might suggest is 
to completely delete both your current CVS and build directories, download a 
fresh copy, and try rebuilding from scratch. It's possible something got 
messed up when you used the configure scripts.

Are you using separate build and source directories? I.e., your source 
directory is named ~/opengc and your build directory is ~/opengcbin (or 
something similar)? If not, I'd suggest doing this under the assumption that 
the makefiles present in the repository could be interfering with the 
makefiles generated by CMake. Incidentally, the executable is named OpenGC 
(note capitalization), and should appear in the root of the build directory 
(i.e. ~/opengcbin/OpenGC ).

Let me know how it goes - I'd like to make sure I'm not the only person who 
can build OpenGC!

-Damion-

_________________________________________________________________
Internet access plans that fit your lifestyle -- join MSN. 
http://resourcecenter.msn.com/access/plans/default.asp

[Opengc-devel] OpenGC and linux using CMake

[Rick M. <ri...@cc...>]

Ok, I found more current install instructions on the web that instruct 
you to use CMake.  Following these, I seem to get further.  At the end 
of the make, I now see the errors

make[3]: *** [latlongc.o] Error 1
make[2]: *** [default_target] Error 2
make[1]: *** [default_target_Source] Error 2
make: *** [default_target] Error 2

I also see that many modules have been built and placed in my Source 
directory (which I assume is a good thing).  No executable has appeared 
(opengc I assume) so I still have a ways to go.  Help would be appreciated.

Rick