[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: Fri, 30 Jun 2000 07:47:35 -0600
Cc: mesa3d-dev@xxxxxxxxxxxxxxx
Organization: Precision Insight, Inc.
References: <200006282033.NAA17628@xxxxxxxxxxxx> <395C5230.F85E7625@xxxxxxxxxxxxxxx>
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
Olivier Michel wrote:
> Thanks to Brian, I checked out and build the lastest CVS version.
> It turns out that the GLU library is now properly built so that C++
> symbols are now defined (i.e., I could like libGLU.so with simple C
> programs).
> However, except for the problems with the glu.h include file which are
> not yet fixed in the CVS, I discovered another problem that didn't exist
> in the tarball version:
> libGLU.so needs a couple of symbols that belongs to SGI libGL.so (I
> guess) and are not present in Mesa libGL.so. These symbols are:
> __glNURBSErrorString and __glTessErrorString
> They are used at the end of main/gfx/lib/glu/libutil/error.c and defined
> as external in gluint.h (in the same directory as error.c)
> I guess GLU should not assume that such symbols are defined in libGL.so
> and I think that the corresponding functions should be moved from SGI GL
> into SGI GLU -> __gluNURBSErrorString and __gluTessErrorString
> I had to comment out these two calls to get SGI libGLU.so link with Mesa
> libGL.so

Have you determined exactly how/why these two functions are used?

libGLU shouldn't use any internal libGL functions, in principle.
But in practice, I'm not too surprised by this.  In the worst case,
I could add those funcs to Mesa (but I'd rather not).

> We are getting closer...

Yup.  Thanks for doing this!


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