[Top] [All Lists]

Re: [ogl-sample] SGI SI GLU integration

To: ogl-sample@xxxxxxxxxxx
Subject: Re: [ogl-sample] SGI SI GLU integration
From: Brian Paul <brian@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 28 Jun 2000 08:23:57 -0600
Cc: mesa3d-dev@xxxxxxxxxxxxxxxxxxxxx
Organization: Precision Insight, Inc.
References: <Pine.SGI.3.96.1000627090303.24381L-100000@xxxxxxxxxxxxxxxxxxxxxxxxxx> <395A09DC.56D83324@xxxxxxxxxxxxxxx>
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
Olivier Michel wrote:
> Hello,
> I wrote the ogl-sample-glu.spec RPM file to produce the RPM package for
> SGI SI GLU and everything seemed fine. I could build the
> ogl-sample-glu-20000126.i386.rpm file properly.
> I also built a mesa-without-glu-280600.i386.rpm for testing SGI SI GLU
> with mesa core GL.
> 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.

> 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

> 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.

> Anyway, I did all that with the downloadable tarball of ogl-sample
> (ogl-sample-20000126.tgz) because I was unable to get the CVS source
> tree version (apparently, there is a broken link on the web page).
> Any help or advices greatly appreciated.

Here's how I get the ogl-sample CVS files:

% cvs -d:pserver:cvs@xxxxxxxxxxx:/cvs login
password is cvs

% cvs -d:pserver:cvs@xxxxxxxxxxx:/cvs co projects/ogl-sample/main


<Prev in Thread] Current Thread [Next in Thread>