I ran into a problem, as I describe below, trying to get OpenInventor
running on a SUN workstation. Any advice would be appreciated.
- first off, somehow it is quite a thrill to participate in the open source
movement, even if my contribution is quite meager!
- all OpenInventor source compiled (albeit with many warnings) on my
SUN ultra 10 with SunOS 5.8 (Solaris 8). Some slight changes
were made to some of the src files (see below).
- the libraries: "libInventor.a", "libInventorXt.a", "libimage.a",
"libInventorWidget.a" were created.
- "SceneViewer" was compiled and linked.
- Upon execution of "SceneViewer", the following crash occurs:
273% ./SceneViewer
X Error of failed request: BadValue (integer parameter out of
range
for operation)
Major opcode of failed request: 91 (X_QueryColors)
Value in failed request: 0xc3b2ae
Serial number of failed request: 624
Current serial number in output stream: 624
I am not well versed on the workings of X so this may be a show stopper
for me. If you recognize this, please let me know. (thanks in advance!)
I will look in the debugger to see where the crash occurs but if I dont
see daylight at the end of the tunnel soon, I may have to pull the rip
cord
and bail out.
- In case it may be helpful to others, here is a blurb of my findings to
this date:
- CHANGES:
- the SUN C++ compiler does not like the ".c++" suffix so I had to
rename such files to end in ".cc".
- I had to "gut" all the methods in "SoTexture2.c++" since it included
"jpeglib.h" which I did not find. (This means SoTexture2 is not
usable but links ok).
- I had to add "#include <sunmath.h>" to appropriate src files that call
"floorf()", "cosf()", "atanf()", etc. If I get this running on the
SUN and it is desirable to migrate these changes back to mother
version, I can get a list of files.
(We could use "#ifdef SomeSunThing".)
- "#ifdef _sgi" is in some includes. (I know it's in "SbLinear.h",
"SbTime.h", and "SbBasic.h" but I did not grep everywhere.)
In "SbTime.h" I had to make the following change since INT32_MAX
was already defined:
#ifndef INT32_MAX <--- my addition.
#ifndef __sgi
#define INT32_MAX INT_MAX
#endif // !__sgi
#endif // svc <--- my addition.
It probably should be looked at closely everywhere.
- An extraneous include in "inventor/libSoXt/src/mixedMode" could not
be found:
"SoXtSlider.cc", line 61: Error: Could not open include
file <stream.h>."
I commented out the include and no errors resulted. I am assuming
it was not needed, possibly placed in there during some debugging?
- The SUN compiler had trouble with "typedef float SbMat[4][4];" in
"SbLinear.h". When a call is made to a method that passes a
reference to an SbMat, the method is not found. The compiler
somehow (erroneously?) is looking for a method with an arg of
type "reference to a float[][4]" which is apparently different than a
"reference to a float[4][4]". So, In "SbLinear.h", I replaced
"typedef float SbMat[4][4];"
with a more concrete definition as follows:
struct float4vector
{
float vals[4][4] ;
float* operator[](int index) const
{ return (float*) this->vals[index] ; }
};
typedef float4vector SbMat ;
Then some minor changes had to be made in a couple of methods
that explicitely declared "float[4][4]" values instead of specifying
the type "SbMat".
"SbMatrix.c++::inverse()" passes the "SbMat" variable "invmat" to
another method but delcares "invmat" explicitely as "float[4][4]". I
made the following change:
//float d, invmat[4][4], temp; // This line commented out!!
float d, temp; // added this line!!!
SbMat invmat ; // added this line!!!
In "SoGLModelMatrixElement.c++",
"SoGLProjectionMatrixElement.c++,
"SoGLTextureMatrixElement.c++",
"SoGLViewingMatrixElement.c++",
"SoGLTextureMatrixElement.c++", I got the following compiler
error:
"line 85: Error: Cannot cast from const float4vector to float*."
So I had to make changes like:
// glMultMatrixf((float *) matrix.getValue()); // removed
glMultMatrixf((float *) matrix.getValue()[0]); // added
since an SbMatrix was now returned instead of a pointer to the first
float value.
- WARNINGS:
- The bad news: there are many, many, many compiler warnings.
(One file produced 139 of them.)
The good news: there are only a few distinct warnings repeated
many times.
The scary news: Until they are cleaned up, I can just cross my
fingers and hope the compiler does the "right" thing.
- string literals. compiler wants pointers to them declared "const".
ex: char* xx = "hello world" ; // bad
const char* xx = "hello world" ; // good
"SoPickStyle.cc", line 81: Warning: String literal converted
to char* in formal argument typeName in call to
SoFieldData::getEnumData(char*, int&, int*&, SbName*&).
Over time this change can be implemented as files are touched.
This requirement may be part of the latest C++ standard.
- "Too few arguments" in "inventor/lib/interaction/src/draggers"
(as well as other places):
"SoTranslate2Dragger.cc", line 90: Warning: Too few arguments
in macro SO__QUOTE.
"Line 90" in the code (notice the missing arg!):
"SO_KIT_ADD_CATALOG_ENTRY(translatorSwitch, SoSwitch, TRUE,
geomSeparator, ,FALSE);
I made no changes here. just crossed my fingers.
- warnings about inexact declarations for callback functions.
"SoShape.cc", line 881: Warning (Anachronism): Formal argument
CallBackFunc of type extern "C" void(*)() in call to
gluTessCallback(GLUtesselator*, unsigned, extern "C" void(*)()) is
being passed void(*)().
This is somewhat scary.
- Many warnings of the kind:
"SoIndexedFaceSet.cc", line 345: Warning: materialBinding hides
SoIndexedShape::materialBinding.
I assume we will have to live with these for a very long time but
you would think the compiler takes the appropriate and obvious
action.
- COMPILING:
- I used compiler version:
"CC: WorkShop Compilers 5.0 98/12/15 C++ 5.0"
(from "CC -V" command)
- I had to specify "-DSUN_OGL_NO_VERTEX_MACROS" on the
compile line for source files that called OpenGL routines using
the scope operator (e.g. "::glColor4fv( p );"). Loosely speaking,
SUN implements OpenGl calls indirectly through some sort of table
of function pointers (via #define) "for performance reasons". The
scope operator "::" says there is a global function to call which
is not found and results in a compiler error. The
"SUN_OGL_NO_VERTEX_MACROS" macro specifies
that the actual OpenGl routines are to be accessed and fixes the
problem. The alternative is to remove the scope operator from the
OpenGl calls.
- "SoText2.c++" and "SoText3.c++" have:
#ifdef IRIX_6
...
#endif
I did not define IRIX_6.
- I specified "-DLIBRARYBUILD" for
"lib/database/src/so/nodes/nurbs/head/*.h" files. (look for
"#ifdef LIBRARYBUILD" in the files.)
- sample compilation in directory "inventor/lib/database/src/so/nodes":
CC -c -mt -DSUN_OGL_NO_VERTEX_MACROS
-DLIBRARYBUILD SoShape.cc
-I. -I../../../../../lib/database/include
-I../../../../../lib/interaction/include
-I../../../../../lib/nodekits/include
-I../../../../../libSoXt/include
-I../../../../../libSoXt/src
-I../../../../../libFL/src
-Inurbs/head -I/usr/include
- I cant remember where, but I think the SUN documentation said to use
the "-mt" flag (thread safe libraries) with OpenGL?.
- LINKING:
- use "-lsunmath" to link "floorf()", "cosf()", "atanf()", etc.
- an excerpt from the "Makefile" in "inventor/apps/demos/SceneViewer":
src_files = SceneViewer.cc SoSceneViewer.cc SvManipList.cc
o_files = $(src_files:%.cc=%.o)
CC -L../../samples/widgets \ // libInventorWidget.a
-L../../../lib \ // libFL.a
-L../../../lib/libFL/src \ //
Inventor,InventorXt,image
-L/usr/openwin/lib \ // X and OpenGL
${o_files} \
../../../lib/interaction/src/SoInteraction.o \ // see NOTE
below.
-lInventorWidget -lInventor -lInventorXt -limage\
-lFL \
-lXm -lXt -lXext -lX11 \
-lGLU -lGL \
-lsunmath -ldl \
-o SceneViewer
NOTE: "SoInteraction methods were not found in "libInventor.a"
even though I archived them. so I
just specified them directly (above) and it found them. I'm
guessing it's the order I archived them into "libInventor.a"
and can revisit that later.
- That's all that come to mind.
---------------------------
Steven Connolly
CSC/Pratt & Whitney
connolsv@xxxxxxxx
---------------------------
|