| > However, I had a couple of problems when trying to get it work:
| > 1) The SGI glu.h file has some problem with Mesa gl.h file:
| > a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa
| > gl.h
| > => idea: either add this typedef to Mesa gl.h,
| > or use something different in SGI glu.h (like *_GLUfuncptr)
| My understanding was the _GLfuncptr was something added in order to
| make work the autogeneration of the header files from the spec files.
| It's supposed to be a private symbol.
| I like the idea of glu.h defining _GLUfuncptr if it needs it.
The glu header generation drafts off of the GL header file generation
and the _GLfuncptr leaked in. Looks like it would be straightforward
to change to use _GLUfuncptr instead.
| > b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are
| > redefined in SGI glu.h (they are previously defined in Mesa gl.h)
| > => idea: move them into SGI gl.h
| glu.h should not define any GL_* tokens. Could you send me your glu.h
yes, these are tokens are defined in the SI glu.h and gl.h and shouldn't
be in the glu.h. This looks like an artifact of the way the files
are generated and shouldn't be too hard to fix.
I can fix both of these if no one objects.
| > 2) The libGLU.so built from the GNUmakefile does not contain the C++
| > symbols like __pure_virtual. This is Ok if you link it with a C++ app,
| > but it causes an undefined symbol when linking with C programs or
| > libraries. I could work around this problem by linking by hand the
| > libGLU.so using g++ instead of ld:
| > g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc.
| > Fixing this would require big change the GNUmakefile and included files
| > in the ogl-sample package. I didn't do it because I was afraid of
| > breaking other things (in the build of other libraries than GLU).
| When you build the libGLU.so shared library, could you add -lg++
| (the C++ runtime lib) to the list of objects? That way, libGLU.so
| would be implicitly linked to libg++.so, so hopefully the end-user
| could use the regular gcc linker.
i think it is a little more troublesome than that (trust me :), but
i think the fix i'm about to check in is the best compromise in
terms of a clean Makefile and not having funny paths like
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66 embedded in the Makefile.