problems with opengl header

[regnnick]

I've updated my nvidia drivers to the latest ia32 version (aka 1.0-5336) including the opengl headears. And now, any C++ program complain about broken glu.h/glext.h (I didn't try C programs). I have the following error messages:
/usr/include/GL/glext.h:3178: type specifier omitted for parameter `boolean'
/usr/include/GL/glext.h:3178: parse error before `*' token

/usr/X11R6/include/GL/glu.h:261: parse error before `*' token
/usr/X11R6/include/GL/glu.h:263: syntax error before `void'
/usr/X11R6/include/GL/glu.h:264: syntax error before `void'
/usr/X11R6/include/GL/glu.h:265: syntax error before `void'
/usr/X11R6/include/GL/glu.h:266: syntax error before `void'
...


The same programs compile fine with the previous drivers and on my opteron computer (with amd64 drivers 1.0-5332)

Any idea why this error occurs?

[nvnothing]

NVidia just made a typo.

/usr/include/GL/glext.h:3178: type specifier omitted for parameter `boolean'
/usr/include/GL/glext.h:3178: parse error before `*' token

FIX:
Change boolean to GLboolean:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, boolean *residences);

becomes:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, GLboolean *residences);


I just found this too with 5336. Probably it crept through because VC++ defines a boolean type for C, whereas gcc doesn't. But that's just a guess. If so, this could cause problems as GLboolean is unsigned char while VC++ boolean might be an int, so the library would have it as 1 unsigned byte while the program would be expecting 4 bytes, signed.

Anyhow 5336 is 20% slower on my Ti4200 than 4496, so I am only using its headers. Mysterious performance problems make me wish for driver source code, not to mention all the headaches poor VIA chipset folks have.

On my system the 3xxx drivers couldn't do TwinView except for Clone -- right and left monitors caused a lockup.

4xxx is slower but works for TwinView, but is prone to occasional lockups. 5xxx is slower still, so I didn't wait around to check its stability.

[regnnick]

Originally posted by nvnothing
NVidia just made a typo.

FIX:
Change boolean to GLboolean:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, boolean *residences);

becomes:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, GLboolean *residences);

In fact, I've already done this change, but thanks . But I still have a problem with the glu.h which is more tricky. I had to suppress the GLAPI and GLAPIENTRY (like in the mesa glu.h) and now it seems to work.

I just found this too with 5336. Probably it crept through because VC++ defines a boolean type for C, whereas gcc doesn't. But that's just a guess. If so, this could cause problems as GLboolean is unsigned char while VC++ boolean might be an int, so the library would have it as 1 unsigned byte while the program would be expecting 4 bytes, signed.

Anyhow 5336 is 20% slower on my Ti4200 than 4496, so I am only using its headers. Mysterious performance problems make me wish for driver source code, not to mention all the headaches poor VIA chipset folks have.

It would be easier for the linux community if these drivers were released under a free licence. I never really understand why it is not possible to open part of the code which is not patent protected and let the rest in a binary file...

[nvnothing]

Perhaps you could quote the problem lines from your GLU file.

My line 261 says:

extern void gluBeginSurface (GLUnurbs* nurb);

Earlier, GLUnurbs is declared as:

#ifdef __cplusplus
class GLUnurbs;
class GLUquadric;
class GLUtesselator;
#else
typedef struct GLUnurbs GLUnurbs;
typedef struct GLUquadric GLUquadric;
typedef struct GLUtesselator GLUtesselator;
#endif

glu.h is not included in the NV driver, so mine is from SGI: "This software was created using the OpenGL(R) version 1.2.1 Sample Implementation published by SGI", according to the comments.

It would be easier for the linux community if these drivers were released under a free licence. I never really understand why it is not possible to open part of the code which is not patent protected and let the rest in a binary file...

Now that ATI has equalled or surpassed NVidia in many ways, I don't see how opening their drivers could cause them to lose their performance edge, as it's already gone.

The other day I was checking out Mesa and they have all the extensions, vertex programs, you name it. We just need an FPGA Mesa board.

[regnnick]

Perhaps you could quote the problem lines from your GLU file.

Here it is

typedef void (GLAPIENTRY *_GLUfuncptr)();

As I said in my previous post, the errors arise from the GLAPI and GLAPIENTRY.

glu.h is not included in the NV driver, so mine is from SGI: "This software was created using the OpenGL(R) version 1.2.1 Sample Implementation published by SGI", according to the comments.

You're right. I don't have the previous gl.h anymore. Do you know if the GLAPI and GLAPIENTRY were defined there?

Big thanks for your help

Now that ATI has equalled or surpassed NVidia in many ways, I don't see how opening their drivers could cause them to lose their performance edge, as it's already gone.

The other day I was checking out Mesa and they have all the extensions, vertex programs, you name it. We just need an FPGA Mesa board.

I agree but I thought the reason why they didn't want to open the code was because of the patent problems.