mesa3d-dev

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

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

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

We are getting closer...

-Olivier

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

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

Good news: It was a bit tricky, but I successfully built 2 RPM binary
packages (for i386)

  ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
mesa-without-glu-3.3.04JUL00-1.i386.rpm

I am not sure the names and version numbering are fine, but that's just
a first trial.

You may use rpm -Uvh with --nodeps or --force to get them installed
properly on differents Linux distros I could test it on Suze 6.4, Redhat
6.0 and Slackware 7.0 and seemed to work properly: the tesselator
doesn't crash my app any more :)

These packages are available at ftp://ftp.cyberbotics.com (you may also
download the other packages to test my app: webots).

I finally found the real problem with building the SGI libGLU from the
current CVS:

In the file glue.c, the functions

static const char *__glNURBSErrorString( int errno )

and

static const char *__glTessErrorString( int errno )

should not be defined as static because they are used by error.c. This
cause the libGLU.so doesn't work at runtime because it doesn't find
these functions called by error.c (which are local to glue.c).

So, the fix is pretty simple: just remove the static keyword for these
two functions in glue.c

Again, since I have no write access to the CVS, I hope someone could do
it for me.

Moreover I had to hack the glu.h problem by hand.

Thanks,

-Olivier

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

[Brian P. <br...@va...>]

Olivier Michel wrote:
> 
> Good news: It was a bit tricky, but I successfully built 2 RPM binary
> packages (for i386)
> 
>   ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
> mesa-without-glu-3.3.04JUL00-1.i386.rpm
> 
> I am not sure the names and version numbering are fine, but that's just
> a first trial.
> 
> You may use rpm -Uvh with --nodeps or --force to get them installed
> properly on differents Linux distros I could test it on Suze 6.4, Redhat
> 6.0 and Slackware 7.0 and seemed to work properly: the tesselator
> doesn't crash my app any more :)
> 
> These packages are available at ftp://ftp.cyberbotics.com (you may also
> download the other packages to test my app: webots).
> 
> I finally found the real problem with building the SGI libGLU from the
> current CVS:
> 
> In the file glue.c, the functions
> 
> static const char *__glNURBSErrorString( int errno )
> 
> and
> 
> static const char *__glTessErrorString( int errno )
> 
> should not be defined as static because they are used by error.c. This
> cause the libGLU.so doesn't work at runtime because it doesn't find
> these functions called by error.c (which are local to glue.c).
> 
> So, the fix is pretty simple: just remove the static keyword for these
> two functions in glue.c
> 
> Again, since I have no write access to the CVS, I hope someone could do
> it for me.
> 
> Moreover I had to hack the glu.h problem by hand.


Olivier,

What's the status on this project?

-Brian

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

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

Hello,

Sorry, I was off last week and I am just back from holidays reading my
142 e-mails...
Apparently Dave commited a number of changes I requested. However, it is
apparently not yet complete (since the glu.h header is not yet fixed, it
still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
currently working working on that...
Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
file still needs to be patched by hand). However, I can provide all what
I have:

1) The method to patch the glu.h and build the rpm from my modified
.spec file. This might be useful to build binary rpms for other
platforms. I will send them upon request.

2) The binary package for linux i386 (it is already available from
ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
a RPM package for Mesa without its GLU).

Otherwise, we have to wait for Dave to fix the glu.h problem and to
add/merge my RPM .spec file to the CVS tree.

I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
appreciate if they could be hosted somewhere else than on my ftp site
(since it cannot support high traffic).

By the way, how should I name the final versions of those packages ?

mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?

Another option could be to merge Mesa and SGI GLU into a single RPM
binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
more tricky, but that's not a problem for me).

Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
everything, but this might be conficting with other versions using Mesa
GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
it from Mesa distribution and recommanding to use SGI GLU instead ?

-Olivier

Brian Paul wrote:
> 
> Olivier Michel wrote:
> >
> > Good news: It was a bit tricky, but I successfully built 2 RPM binary
> > packages (for i386)
> >
> >   ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
> > mesa-without-glu-3.3.04JUL00-1.i386.rpm
> >
> > I am not sure the names and version numbering are fine, but that's just
> > a first trial.
> >
> > You may use rpm -Uvh with --nodeps or --force to get them installed
> > properly on differents Linux distros I could test it on Suze 6.4, Redhat
> > 6.0 and Slackware 7.0 and seemed to work properly: the tesselator
> > doesn't crash my app any more :)
> >
> > These packages are available at ftp://ftp.cyberbotics.com (you may also
> > download the other packages to test my app: webots).
> >
> > I finally found the real problem with building the SGI libGLU from the
> > current CVS:
> >
> > In the file glue.c, the functions
> >
> > static const char *__glNURBSErrorString( int errno )
> >
> > and
> >
> > static const char *__glTessErrorString( int errno )
> >
> > should not be defined as static because they are used by error.c. This
> > cause the libGLU.so doesn't work at runtime because it doesn't find
> > these functions called by error.c (which are local to glue.c).
> >
> > So, the fix is pretty simple: just remove the static keyword for these
> > two functions in glue.c
> >
> > Again, since I have no write access to the CVS, I hope someone could do
> > it for me.
> >
> > Moreover I had to hack the glu.h problem by hand.
> 
> Olivier,
> 
> What's the status on this project?
> 
> -Brian

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

[Brian P. <br...@va...>]

Olivier Michel wrote:
> 
> Hello,
> 
> Sorry, I was off last week and I am just back from holidays reading my
> 142 e-mails...
> Apparently Dave commited a number of changes I requested. However, it is
> apparently not yet complete (since the glu.h header is not yet fixed, it
> still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
> currently working working on that...
> Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
> file still needs to be patched by hand). However, I can provide all what
> I have:
> 
> 1) The method to patch the glu.h and build the rpm from my modified
> .spec file. This might be useful to build binary rpms for other
> platforms. I will send them upon request.
> 
> 2) The binary package for linux i386 (it is already available from
> ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
> a RPM package for Mesa without its GLU).
> 
> Otherwise, we have to wait for Dave to fix the glu.h problem and to
> add/merge my RPM .spec file to the CVS tree.
> 
> I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
> Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
> appreciate if they could be hosted somewhere else than on my ftp site
> (since it cannot support high traffic).

You shouldn't have to wait for a Mesa release to put out the SI GLU
package.

I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute
bug regression in evaluators is postponing that, probably until after
SIGGRAPH.  Dave's probably busy preparing for SIGGRAPH too.

So, I might be two weeks before we're all ready.


> By the way, how should I name the final versions of those packages ?
> 
> mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
> Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?

I prefer the later.


> Another option could be to merge Mesa and SGI GLU into a single RPM
> binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
> Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
> more tricky, but that's not a problem for me).

I'd rather keep the packages separate.  I expect that the GLU package
won't be updated as often as Mesa.  Also, it would make the Mesa package
smaller.


> Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
> everything, but this might be conficting with other versions using Mesa
> GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
> it from Mesa distribution and recommanding to use SGI GLU instead ?

Yes, I'd like to drop Mesa's GLU at some point but I haven't worked
out the details.

-Brian

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

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

Brian Paul wrote:
> 
> Olivier Michel wrote:
> >
> > Hello,
> >
> > Sorry, I was off last week and I am just back from holidays reading my
> > 142 e-mails...
> > Apparently Dave commited a number of changes I requested. However, it is
> > apparently not yet complete (since the glu.h header is not yet fixed, it
> > still includes the OpenGL 1.0 compatibility lines), but I guess Dave is
> > currently working working on that...
> > Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h
> > file still needs to be patched by hand). However, I can provide all what
> > I have:
> >
> > 1) The method to patch the glu.h and build the rpm from my modified
> > .spec file. This might be useful to build binary rpms for other
> > platforms. I will send them upon request.
> >
> > 2) The binary package for linux i386 (it is already available from
> > ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with
> > a RPM package for Mesa without its GLU).
> >
> > Otherwise, we have to wait for Dave to fix the glu.h problem and to
> > add/merge my RPM .spec file to the CVS tree.
> >
> > I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and
> > Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would
> > appreciate if they could be hosted somewhere else than on my ftp site
> > (since it cannot support high traffic).
> 
> You shouldn't have to wait for a Mesa release to put out the SI GLU
> package.

Sure. It is already available on ftp://ftp.cyberbotics.com and is not
likely to change when Mesa-3.3 is out. I will eventually rebuild it if
bug fixes are commited.

> I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute
> bug regression in evaluators is postponing that, probably until after
> SIGGRAPH.  Dave's probably busy preparing for SIGGRAPH too.
> 
> So, I might be two weeks before we're all ready.

All right.

> > By the way, how should I name the final versions of those packages ?
> >
> > mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply
> > Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ?
> 
> I prefer the later.

That's fine for me.

> > Another option could be to merge Mesa and SGI GLU into a single RPM
> > binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply
> > Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit
> > more tricky, but that's not a problem for me).
> 
> I'd rather keep the packages separate.  I expect that the GLU package
> won't be updated as often as Mesa.  Also, it would make the Mesa package
> smaller.
>
> > Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing
> > everything, but this might be conficting with other versions using Mesa
> > GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove
> > it from Mesa distribution and recommanding to use SGI GLU instead ?
> 
> Yes, I'd like to drop Mesa's GLU at some point but I haven't worked
> out the details.
> 
> -Brian

It's not easy because the demos and examples need a GLU to work...

-Olivier

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

[Brian P. <br...@pr...>]

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

[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