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!
-Brian
|