[lsb-discuss] glext.h

Craig.Scott at csiro.au Craig.Scott at csiro.au
Sun Jun 19 20:19:59 PDT 2011

On 18/06/2011, at 7:02 AM, Wichmann, Mats D wrote:

> When glext.h and glxext.h were imported, I guess only those constants that seemed to have applicability were added.  There's nothing wrong with adding a bunch more, but what version of these files are the appropriate ones to capture?  We reference an ancient - neolithic, even - version of OpenGL itself.  Is it correct to have very up to date extension headers?  I see the very latest are GL_GLEXT_VERSION 70  (a constant we don't even define, sigh) and GLX_GLXEXT_VERSION 32 (this one we define, and it has a value of 6).

The glext.h header provides the constants and the function pointer types for that are *not* provided by the system. You would use these, for example, if you are building on a system that only has support for OpenGL 1.2, but you wanted to be able to use things from OpenGL 2.1 if they were available on the system that the binaries were eventually run on.

The glext.h header provides the standardisation that allows you to use things from more recent OpenGL versions even if the software is built against older OpenGL versions. Given how far the LSB lags behind current OpenGL versions, having the most recent glext.h would seem to be a good way to address the issue for those ISV's who want/need to use more recent OpenGL support without placing any additional constraints/requirements on linux distribution vendors. ISV's in this position would simply specify that the target system requires a video driver with support for some minimum OpenGL version, which is usually provided by a vendor-specific driver anyway for users doing any sort of serious OpenGL work and this will never be part of the LSB. Note also that this also meets the needs of those who want to make use of more recent OpenGL capabilities if available but can fall back to what an earlier OpenGL provides if required.

Note also that if the system-supplied (or LSB-supplied) gl.h header is properly formed, then having the LSB SDK provide the most recent glext.h should not cause any issues, since it is designed to test for the things gl.h would define and then augment that with symbols from later OpenGL versions. By default, none of the things glext.h defines should reference any binary things, glext.h only defines constants and types so it introduces no binary symbol dependencies, etc. You can explicitly enable an switch to force it to define function prototypes instead of the associated types, but this is not the way I'd expect most people to use glext.h (and not something I think the LSB needs to concern itself with in my view).

I am less familiar with the GLX equivalent (ie glxext.h) since we don't use that, but I would imagine that the situation is analogous.

Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

More information about the lsb-discuss mailing list