Compiling on Irix 6.5

[dexter1]

Hello all,

I'm attempting to compile celestia 1.3.0 on my SGI IRIX machines. I started this port about 4 months ago, but got caught up with lots of work. Here's what i got so far:

Celestia 1.3.0 can be compiled on IRIX provided you use a late compiler revision like 7.4.x, i use MIPSPro 7.4.1 on a 6.5.21m and 6.5.22m IRIX machine.

The Ominous "glXGetProcAddressARB" is in fact a function only implemented on linux, but not in IRIX. I have fixed this using a generic library call construct, see this thread on our IRIX forum: http://www.nekochan.net/phpBB2/viewtopic.php?t=1136

Currently the GTK code behaves so badly it triggers a segfault deep in the overlay code.

So i reverted to Qt 3.1.2 and KDE 3.1.4 and i have almost finished modified celestia code for this. I have to completely rebuild all these apps for my machine, there seems to be no alternative, except for GTK, but that one doesn't work (yet). I expect to get results in the weekend.

I will also try the 1.3.1 version.

Thanks a lot for celestia BTW, it looks to be one of the nicest opensource GL program i come accross.

[dexter1]

Well, i had 1.3.0 compiled on IRIX but the QT/KDE frontend crashes similarly to the GTK frontend on IRIX. No screen, just building the star database, complaining about:
Parent body 'TYC 5503-946-1' of 'b' not found., then
render path: 0
...and that's it.

So is there a way of disabling both frontends? I saw mentioning of GLUT, but how do i enable that?

And what about endianness? Does it run on Ultrasparcs?

[selden]

Not having access to an SGI system, I can't help in detail, but...

Neither of the messages you mention are indications of fatal errors.

Parent body 'TYC 5503-946-1' of 'b' not found.

means that the stars database and "extrasolar.ssc" loaded successfully at runtime. It is correctly telling you that there's a planet listed in "extrasolar.ssc" which is orbiting a star that isn't in the Hipparcos database. Since there are no other errors like that, this says that stars.dat loaded correctly and the other exoplanets were loaded, too.

render path: 0
means that Celestia has decided that it can only use what it calls "Basic" OpenGL rendering and that the next higher level of rendering sophistication "Multitextures" is not available.

I hope this helps a little.
You're getting close!

[dexter1_]

Well, we're into late february and in the meantime i tried debugging celestia 1.3.0/IRIX 6522m/MIPSPro7.4.1 with all three output options: GTK KDE and GLUT

It all boils down to a segfault in the celengine/overlay.cpp code:

Stack Trace:

Code: Select all

std::basic_streambuf<char,std::char_traits<char> >::pubimbue(<stripped>) ["streambuf.cxx":23]
std::basic_ios<char,std::char_traits<char> >::imbue(this = 0x10575e84, <no name> = 0x7fff2c54, __loc = 0x7fff2c50) ["ios":487]
std::basic_ios<char,std::char_traits<char> >::init(this = 0x10575e84, __sb = 0x10575e4c) ["ios":506]
std::basic_ostream<char,std::char_traits<char> >::basic_ostream<char,std::char_traits<char> >(this = 0x10575e30, <no name> = 0x10575e84, __buf = 0x10575e4c) ["ostream":255]
Overlay::Overlay(this = 0x10575e30, <no name> = 0x10575e84) ["overlay.cpp":19]
CelestiaCore::initRenderer(this = 0x102747f8) ["celestiacore.cpp":2918]
main(argc = 1, argv = 0x7fff2ef4) ["glutmain.cpp":510]
__start(<stripped>) ["crt1text.s":177]


This is hard to debug! It's probably the <no name> pointer which gets passed to the Overlay() function and from there to the basic ostream, but i'm just too dumb to understand C++ thoroughly. The only option i see is to debug a linux machine next to it and start disecting the entire stack and memory dump.

I could really really use some help here

[dexter1_]

Since i got no help in solving this, and i am already on this since july 2003, i haven't looked at this in a long time. Recently after a full week of debugging, i can now say with reasonable accuracy that i have pinpointed the problem. Being a complete dumbass in C++ i can't vouch for my correctness in explaining the problem properly, but i'll give it a shot:

The problem is indeed src/celengine/overlay.cpp. A snippet (both 1.3.0 and 1.3.1 have this):

Code: Select all

Overlay::Overlay() :
    ostream(&sbuf),
    windowWidth(1),
    windowHeight(1),
    font(NULL),
    useTexture(false),
    fontChanged(false),
    textBlock(0)
{
    sbuf.setOverlay(this);
}

The last class sbuf.setOverlay(this) DOES NOT WORK on SGI MIPSPro compiles. I've tried to debug this, but it causes horrible segfaults and stack corruption. Damn.

I went back to the original celestia-1.0.8 version which i've ported to SGI IRIX. Some basic endinanness aside, which i've fixed, the program crashes at sbuf.setConsole(this) in console.cpp and sbuf.setOverlay(this) in overlay.cpp. Grand. This raises my suspicion that this snippet of code is not correct C++. I ofcourse cannot decide, because i don't know C++, but i trust MIPSPro compiler over g++ any day of the week.

There was a recent posting about the "this"-pointer and some problems with iostream:

here is the code:

Code: Select all

// begin
#include <iostream>

using namespace std;

class dummy {
 int llama;
};

class mystreambuf : public dummy, public streambuf {
 public:
   mystreambuf()
     : five(5) {
     cout << "dummy pointer= " << (void *)(dummy *)this << endl;
     cout << "streambuf pointer= " << (void *)(streambuf *)this << endl;

     cout << "mystreambuf pointer= " << (void *)this << endl;
     cout << "mystreambuf::five= " << five << endl << endl;
   }
 protected:
   int underflow() {
     cout << "underflow() this= " << (void *)this << endl;
     cout << "underflow() five= " << five << endl;

     return EOF;
   }

   int five;
};

int main() {
 class mystreambuf strbuf;
 istream is(&strbuf);
 char ch;

 is >> ch;

 return 0;
}
// end

Now i don't know if this is relevant to the overlay bug, but lets just look at the output of my PIV/Slackware9.1.0/Linux2.4.25/gcc3.2.2:

Code: Select all

neo:/tmp>./thisp
dummy pointer= bffff82c
streambuf pointer= bffff7f0
mystreambuf pointer= bffff7f0
mystreambuf::five= 5

underflow() this= bffff7f0
underflow() five= 5

And my Challenge S/R4400@175MHz/IRIX6.5.20m/MIPSPro7.41:

Code: Select all

ceres /tmp> ./thisp
dummy pointer= 7fff2e70
streambuf pointer= 7fff2e74
mystreambuf pointer= 7fff2e70
mystreambuf::five= 5

underflow() this= 7fff2e70
underflow() five= 5

So the streambuf and mystreambuf pointer on gcc are the same, whereas they differ, as it should, in MIPSPro. Intel cc on Linux has the same behaviour as gcc. Could this have something to do with the overlay bug, depending on a gcc abnormality? and What about VC++?

I welcome any suggestions/improvements/alternatives for the overlay streambuf code.

Let me finish by saying that i am completely determined to port this to IRIX, even if this means i have to do another year of debugging. I WILL get this app to run on my IRIX machines!

[dexter1_]

Since i got no help in solving this, and i am already on this since july 2003, i haven't looked at this in a long time. Recently after a full week of debugging, i can now say with reasonable accuracy that i have pinpointed the problem. Being a complete dumbass in C++ i can't vouch for my correctness in explaining the problem properly, but i'll give it a shot:

The problem is indeed src/celengine/overlay.cpp. A snippet (both 1.3.0 and 1.3.1 have this):

Code: Select all

Overlay::Overlay() :
    ostream(&sbuf),
    windowWidth(1),
    windowHeight(1),
    font(NULL),
    useTexture(false),
    fontChanged(false),
    textBlock(0)
{
    sbuf.setOverlay(this);
}

The last class sbuf.setOverlay(this) DOES NOT WORK on SGI MIPSPro compiles. I've tried to debug this, but it causes horrible segfaults and stack corruption. Damn.

I went back to the original celestia-1.0.8 version which i've ported to SGI IRIX. Some basic endinanness aside, which i've fixed, the program crashes at sbuf.setConsole(this) in console.cpp and sbuf.setOverlay(this) in overlay.cpp. Grand. This raises my suspicion that this snippet of code is not correct C++. I ofcourse cannot decide, because i don't know C++, but i trust MIPSPro compiler over g++ any day of the week.

There was a recent posting about the "this"-pointer and some problems with iostream:

here is the code:

Code: Select all

// begin
#include <iostream>

using namespace std;

class dummy {
 int llama;
};

class mystreambuf : public dummy, public streambuf {
 public:
   mystreambuf()
     : five(5) {
     cout << "dummy pointer= " << (void *)(dummy *)this << endl;
     cout << "streambuf pointer= " << (void *)(streambuf *)this << endl;

     cout << "mystreambuf pointer= " << (void *)this << endl;
     cout << "mystreambuf::five= " << five << endl << endl;
   }
 protected:
   int underflow() {
     cout << "underflow() this= " << (void *)this << endl;
     cout << "underflow() five= " << five << endl;

     return EOF;
   }

   int five;
};

int main() {
 class mystreambuf strbuf;
 istream is(&strbuf);
 char ch;

 is >> ch;

 return 0;
}
// end

Now i don't know if this is relevant to the overlay bug, but lets just look at the output of my PIV/Slackware9.1.0/Linux2.4.25/gcc3.2.2:

Code: Select all

neo:/tmp>./thisp
dummy pointer= bffff82c
streambuf pointer= bffff7f0
mystreambuf pointer= bffff7f0
mystreambuf::five= 5

underflow() this= bffff7f0
underflow() five= 5

And my Challenge S/R4400@175MHz/IRIX6.5.20m/MIPSPro7.41:

Code: Select all

ceres /tmp> ./thisp
dummy pointer= 7fff2e70
streambuf pointer= 7fff2e74
mystreambuf pointer= 7fff2e70
mystreambuf::five= 5

underflow() this= 7fff2e70
underflow() five= 5

So the streambuf and mystreambuf pointer on gcc are the same, whereas they differ, as it should, in MIPSPro. Intel cc on Linux has the same behaviour as gcc. Could this have something to do with the overlay bug, depending on a gcc abnormality? and What about VC++?

I welcome any suggestions/improvements/alternatives for the overlay streambuf code.

Let me finish by saying that i am completely determined to port this to IRIX, even if this means i have to do another year of debugging. I WILL get this app to run on my IRIX machines!

[dexter1_]

Bingo!



Got celestia-1.3.0 finally running on my O2. Here's what i did:
Because this "this-pointer" in overlay.cpp is a gcc-ism i replaced

Code: Select all

ostream(&sbuf)

in:

Code: Select all

Overlay::Overlay() :
    ostream(&sbuf),
    windowWidth(1),
    windowHeight(1),
    font(NULL),
    useTexture(false),
    fontChanged(false),
    textBlock(0)
{
    sbuf.setOverlay(this);
}

with

Code: Select all

ostream(NULL)

This way, all the overlays are shot, but atleast i get a nice window with Io and Jupiter in the background, be it with red channel only. Must be some viewport issue...

Well, you're off the hook! I'll file a bit on my patches and will submit them to sourceforge maintainer or CVS.[list=][/list]