Khronos Public Bugzilla
Bug 730 - #define GL_EXT_texture_compression_s3tc missing in glext.h
Summary: #define GL_EXT_texture_compression_s3tc missing in glext.h
Alias: None
Product: OpenGL
Classification: Unclassified
Component: Registry (show other bugs)
Version: unspecified
Hardware: All All
: P3 minor
Target Milestone: ---
Assignee: Jon Leech
QA Contact:
Depends on:
Reported: 2012-10-10 12:41 PDT by Brian Paul
Modified: 2013-06-13 03:46 PDT (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Paul 2012-10-10 12:41:02 PDT
The extension token GL_EXT_texture_compression_s3tc is not defined in glext.h so a bit of app code like this:

#ifdef GL_EXT_texture_compression_s3tc

would be compiled away.

glext.h has #defines for GL_EXT_texture_compression_latc and GL_EXT_texture_compression_rgtc, etc. but not for GL_EXT_texture_compression_s3tc.  Seems to be a simple oversight.

I haven't examined glext.h for other similar omissions.
Comment 1 Alfonse 2012-10-10 14:23:32 PDT
You should know that those #defines are not used to detect whether the implementation provides the extension. That must be done at *runtime* by querying the extension string.

Also, only extensions that provide new functions get the #define. It's to prevent multiple typedefs for the same function.
Comment 2 Brian Paul 2012-10-10 14:53:02 PDT
You should know there's two aspects to OpenGL extensions testing: compile-time AND run-time.  This bug deals with the former only.

At compile time you need to check if the extension tokens (and typedefs, etc) that you want to use are actually present.  This is especially important for open-source software which may be built on a wide variety of systems which may have different versions of the gl.h and glext. headers.

Extensions that only provide new tokens also get the #define, for example: GL_EXT_texture_compression_latc and GL_EXT_texture_compression_rgtc.
Comment 3 Jon Leech 2013-06-13 03:46:29 PDT
This should be fixed in the new XML API Registry and in the
headers generated from that; see

We don't plan to maintain the old .spec files going forward and it
will not be fixed there; we'd like people to migrate to using the
XML registry for whatever external purposes they might be using
.spec for today, because .spec files are just too painful for us
to keep maintaining.