[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OpenInventor on SUN, X error




  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@pweh.com
 ---------------------------