[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:
> 
> 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).

Ok, I found the problem:

Despite their strange names, I was wrong saying that these symbols were
belonging to core GL. I finally found them in glu/libutil/glue.c. They
were not found at run time because the GLU library is build without the
-fpic option. I recompiled the glue.c and error.c files by hand simply
adding the -fpic option to gcc and it worked fine. Symbols are not
anymore missing at runtime.

However, since I have no write access to ogl-sample CVS, I cannot commit
anything to fix this. I guess this is pretty simple to fix (just add
-fpic for Linux compilation in the main/root/usr/include/make/commondefs
which is included by all GNUmakefile).

Anyone with write access to CVS could fix this ?

Thanks,

-Olivier