[lsb-discuss] glext.h

[Craig.Scott at csiro.au]

Hi all. I have a question regarding the glext.h header that is included in the lsb SDK. This particular header is a bit special in what it provides. Specifically, it provides definitions of constants rather than function prototypes or variables, and these constants are all very well defined (dare I say "standard"?) for OpenGL extensions. In fact, the Khronos group even provide a glext.h that developers should be able to simply drop in to their build to replace or stand in for a missing glext.h on their system.

What I'm wondering is if there is anything stopping the lsb from simply including this Khronos-provided glext.h header in the lsb SDK instead of the one it currently provides? The current glext.h is missing a lot of stuff, and this makes it harder for people who actually want/need to use some of the things it provides (like us!). More importantly for devs/ISV's though is that the glext.h provided by the Khronos group is really what is considered the "standard" or "canonical" version of the header. It should be completely platform independent - it is all just constants provided by #define's plus some types. If the lsb SDK could simply include the glext.h from Khronos, it would improve robustness of the SDK since that glext.h will be well-tested and will also be what devs/ISV's are expecting to be available anyway. There doesn't seem to be much point in trying to make the lsb build its own glext.h when a fully complete and more widely tested header is already available.

Note that the gl.h header pulls in glext.h, which is where this whole area starts getting important. For us, we have to provide our own glext.h (which is an unmodified copy of the Khronos group's glext.h) because we need GL constants/types that it provides but which the lsb SDK version does not. We then use these at run-time to test for the presence of certain GL features, since the user's graphics driver will generally provide things beyond what the LSB formally covers. OpenGL provides safe mechanisms for doing these tests, but you need the contents of the glext.h header to use it and this is where having the fully populated Khronos-provided version of glext.h makes a difference.

If you try to include the Khronos' glext.h after the lsb SDK's glext.h, you get symbol redefinition warnings, so it has to be one or the other. There is a symbol you can define before including gl.h to allow you to provide your own glext.h later and I have just reported a bug related to this in the LSB bug tracker (this bug currently prevents us from working around the incomplete glext.h provided by the lsb without using a fragile hack that depends on the name of the header guard used within the lsb-provided glext.h):

http://bugs.linuxbase.org/show_bug.cgi?id=3263


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