Thread: [Opengc-devel] Compiling the latest version of openGC with CYGWIN
Status: Pre-Alpha
Brought to you by:
madmartigan
Menu
▾
▴
opengc-devel
|
From: Stein,Jeffrey L. <js...@mi...> - 2003-10-22 17:00:19
|
Hi all, I was wondering if anybody has managed to compile the lastest version of OpenGlass cockpit on cygwin. I did a co install on linux and cygwin and while I found both installs were quite buggy, especially the building of the FTGL libraries finally we managed to get the linux version working. The cygwin install, however, ran into some issues. Two cpp files would not compile at first but then I managed to fix those issues. Currently after about 6 hrs of trying I have given up. I can build the app but it is not linking correctly. Before I post detailed information I was wondering if anybody has in fact managed to compile under cygwin / gcc lately. Any help would be appreciated. I will try to debug the linking errors later today. -Jeff Stein |
|
From: Damion S. <da...@op...> - 2003-10-22 19:36:00
|
Hi,
Please go ahead and send the detailed information on the linking
errors. I tested the CVS version under both Windows (Visual Studio) and
Mac (gcc) and they both compiled & linked without problems.
Offhand, I suspect that the linking problem is related to how CMake
does or does not detect Cygwin as a valid Unix/Win32 system. Is the
_WIN32 symbol defined during GCC compiles under Cygwin? Right now, the
logic is set up something like:
Is the system Win32?
Yes. Use Windows OpenGL API.
Is the system Unix?
Is it a Mac?
Yes. Use the Carbon GL framework.
No. Use the X11 GL framework.
I have used cygwin very little, and from what I've read online, _WIN32
is not defined as a valid compiler symbol under GCC in cygwin. This
means that the system would detect the OS as Unix, but not Mac, and
would try to use the X11 GL libraries (which is not correct either).
Some additional poking around suggests that the following procedure may
work, though I have not tested it. CMake is used to build the
Visualization Toolkit as well, and it sounds like similar linker errors
were encountered. Their solutions was:
---<snip>---
1. cmake. You need to have cmake running under CYGWIN. This is
available
as a standard package now. You can install it from any CYGWIN
distribution
mirror. This sure beats building it by hand.
2. opengl header files. You must move or delete the opengl headers in
/usr/X11R6/include/GL (gl.h, glu.h,.....). These header files are not
congruent with opengl32. The -I flag in the makefile forces these
header
files to be found first, if they are present. If you fail to do this,
you
will get a bunch of undefined library errors when you try to link the
vtk
libraries with an application. The correct headers are present as part
of
the w32api package.
3. w32api. You must have a recent version of w32api. This insures that
your build will correctly reference opengl-1.1. I suggest installing
the
lastest one from a CYGWIN distribution mirror.
---<snip>---
The full text of the message I grabbed that procedure from can be found
at http://public.kitware.com/pipermail/vtkusers/2003-January/015655.html
Let me know if there's anything else I can help you with, or if you
want me to take a look at the link errors.
Cheers,
-Damion-
On Wednesday, October 22, 2003, at 11:08 AM, Stein,Jeffrey L. wrote:
> Hi all,
>
> I was wondering if anybody has managed to compile the lastest version
> of OpenGlass cockpit on cygwin. I did a co install on linux and
> cygwin and while I found both installs were quite buggy, especially
> the building of the FTGL libraries finally we managed to get the linux
> version working. The cygwin install, however, ran into some issues.
> Two cpp files would not compile at first but then I managed to fix
> those issues.
>
> Currently after about 6 hrs of trying I have given up. I can build
> the app but it is not linking correctly. Before I post detailed
> information I was wondering if anybody has in fact managed to compile
> under cygwin / gcc lately.
>
> Any help would be appreciated. I will try to debug the linking errors
> later today.
>
> -Jeff Stein
---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me
a lot of money."
|
|
From: Stein,Jeffrey L. <js...@mi...> - 2003-10-22 22:32:37
|
Ok, So I deceided to start from scratch. I downloaded a clean cvs developer copy of open gc. First step was to compile the ExternalLibaries compiled: freetype-2.1.0.tar.gz (works) Upon trying to comiple FTGL I run into an error: Freetype Version >= 9.0.3 ... It says I need a different version of freetype to install. In previous itterations of this cygwin process I downloaded a newer version of freetype(2.1.5) for example and this seemed to over come this problem. What version of freetype do you reccomend using? I would assume the one in the developer archive would be correct, if this isnt the case please let me know. I was able to compile FTGL with freetype-2.1.5 i think, but its possible I ran into additional issues with an FT_Open_Flag call in openGlassCockpit which does not exist anymore in freetype-2.1.5 As I seem unable to get past this initial setp, I'll wait for more information before I start hacking away trying to make things work. |
|
From: Stein,Jeffrey L. <js...@mi...> - 2003-10-23 02:59:45
|
The following has been tested on both a linux build and a windows visual c++ build of open glass cockpit. In trying to load a texture in a gauge constructor the texture is never displayed. However if the texture is loaded in the gauges render loop it displays fine. We suspect that openGL is not correctly initialized to the point that it is able to hold textures during the time that gauges are constructed. Does anybody have any information on this? -Jeff |
|
From: Damion S. <da...@op...> - 2003-10-23 05:13:01
|
Hi, It's possible that because of the way in which FLTK does things that the OpenGL device context was not correctly initialized while the gauges were being loaded. I modified the AppObject class to force a display redraw prior to loading the gauges; assuming your code was working fine in the render loop, this is the only event that was NOT occurring prior to the gauges being loaded. Grab a CVS update and let me know if this fixed your problem. -Damion- On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote: > The following has been tested on both a linux build and a windows > visual c++ build of open glass cockpit. > In trying to load a texture in a gauge constructor the texture is > never displayed. However if the texture is loaded in the gauges > render loop it displays fine. We suspect that openGL is not correctly > initialized to the point that it is able to hold textures during the > time that gauges are constructed. Does anybody have any information > on this? > > -Jeff --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
|
From: Stein,Jeffrey L. <js...@mi...> - 2003-10-28 15:37:13
|
As far as I can tell this fix did not solve the problem. I updated the ogcAppObject code with the change you suggested. We still have the same problem where when instantiated in the constructor the texture will not draw, where as when instantiated in the render loop it will draw. I tested on both windows and linux to no avail. Do you have any other ideas? -Jeff Damion Shelton wrote: > Hi, > > It's possible that because of the way in which FLTK does things that > the OpenGL device context was not correctly initialized while the > gauges were being loaded. I modified the AppObject class to force a > display redraw prior to loading the gauges; assuming your code was > working fine in the render loop, this is the only event that was NOT > occurring prior to the gauges being loaded. Grab a CVS update and let > me know if this fixed your problem. > > -Damion- > > On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote: > >> The following has been tested on both a linux build and a windows >> visual c++ build of open glass cockpit. >> In trying to load a texture in a gauge constructor the texture is >> never displayed. However if the texture is loaded in the gauges >> render loop it displays fine. We suspect that openGL is not >> correctly initialized to the point that it is able to hold textures >> during the time that gauges are constructed. Does anybody have any >> information on this? >> >> -Jeff > > > --------- > Damion Shelton > The Open Source Glass Cockpit Project (OpenGC) > Carnegie Mellon University, Robotics Institute > http://www.opengc.org > da...@op... > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel |
|
From: Damion S. <be...@cs...> - 2003-10-28 20:01:50
|
Ok, I have a couple other ideas I can try. Is there some example code you can send me so that I can replicate the problem? It might make debugging easier. -Damion- On Tuesday, October 28, 2003, at 10:32 AM, Stein,Jeffrey L. wrote: > As far as I can tell this fix did not solve the problem. I updated > the ogcAppObject code with the change you suggested. We still have > the same problem where when instantiated in the constructor the > texture will not draw, where as when instantiated in the render loop > it will draw. I tested on both windows and linux to no avail. > Do you have any other ideas? > -Jeff > > Damion Shelton wrote: > >> Hi, >> >> It's possible that because of the way in which FLTK does things that >> the OpenGL device context was not correctly initialized while the >> gauges were being loaded. I modified the AppObject class to force a >> display redraw prior to loading the gauges; assuming your code was >> working fine in the render loop, this is the only event that was NOT >> occurring prior to the gauges being loaded. Grab a CVS update and let >> me know if this fixed your problem. >> >> -Damion- >> >> On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote: >> >>> The following has been tested on both a linux build and a windows >>> visual c++ build of open glass cockpit. >>> In trying to load a texture in a gauge constructor the texture is >>> never displayed. However if the texture is loaded in the gauges >>> render loop it displays fine. We suspect that openGL is not >>> correctly initialized to the point that it is able to hold textures >>> during the time that gauges are constructed. Does anybody have any >>> information on this? >>> >>> -Jeff >> >> >> --------- >> Damion Shelton >> The Open Source Glass Cockpit Project (OpenGC) >> Carnegie Mellon University, Robotics Institute >> http://www.opengc.org >> da...@op... >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by OSDN developer relations >> Here's your chance to show off your extensive product knowledge >> We want to know what you know. Tell us and you have a chance to win >> $100 >> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >> _______________________________________________ >> Opengc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opengc-devel > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel > > --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I wish I would have a real tragic love affair and get so bummed out that I'd just quit my job and become a bum for a few years, because I was thinking about doing that anyway. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X