xref: /third_party/openGLES/ABI/index.php

<?php
$static_title = 'OpenGL&reg; Application Binary Interface for Linux';
$static_breadcrumb = array(
    '/registry/' => 'Registry',
    '/registry/OpenGL' => 'OpenGL',
    'NOLINK' => 'ABI'
);
include_once("../../../assets/static_pages/khr_page_top.php");
?>


<h1 style="text-align:center">
    OpenGL&reg; Application Binary Interface for Linux <br/>
    <span style="font-size:12px"> (formerly Linux/OpenGL Base) </span>
</h1>

<p style="text-align:center">Version 1.0<br/>
   Approved June 20, 2000<br/>
   Editor: Jon Leech, SGI </p>

<hr/>

<h6>Latest News</h6>

<p> Version 1.0 is complete. It was approved on June 20, 2000; all
    submitted votes were in favor. </p>

<hr/>

<h6>Index</h6>

    <ul>
    <li><a href="#1">1. Overview and Goals </a></li>
    <li><a href="#2">2. Calling Conventions</a></li>
    <li><a href="#3">3. Libraries</a></li>
    <li><a href="#4">4. Header Files</a></li>
    <li><a href="#5">5. Extension Headers</a></li>
    <li><a href="#6">6. Feedback and Mailing Lists</a></li>
    <li><a href="#app">Appendix: Open Issues</a></li>
    <li><a href="#log">Change Log</a></li>
    </ul>

<p> <a name="1"></a></p>
<h6>1. Overview and Goals </h6>

<p> 1.1. This document is intended to solve two related problems. First,
    defining the ABI and runtime environment for applications using
    OpenGL under X11 on Linux. This will enable applications using the
    OpenGL API for rendering to run on a variety of underlying
    implementations transparently. The intent is to address all of open
    source, commercial closed binary, OpenGL SI-based, and Mesa-based
    implementations. </p>

<p> Second, defining the SDK for developing apps using OpenGL. This
    includes header file locations, conventions for use of extensions,
    etc. </p>

<p> It has similar goals to the <a href="http://www.linuxbase.org">Linux
    Standard Base</a>, but focused much
    more narrowly: on the OpenGL API. Representatives from LSB are
    involved and ultimately this effort should be part of LSB. </p>

<p> We do not exactly track all LSB practice (particularly naming
    conventions for libraries) because LSB itself is not complete, and
    because existing practice with other OpenGL implementations suggests
    preferred methods which may differ from LSB. </p>

<p> 1.2. Things we do <b>not</b> attempt to address include: </p>

    <ul>
    <li> Internal implementation dependent issues - details of direct
        rendering, loadable driver modules, etc. Such details are
        hidden from the public interfaces by the implementation,
        and are irrelevant to applications using the ABI. </li>
    <li> Operating systems other than Linux. Other platforms such as BSD
        are welcome to use whatever comes out of this project, but we
        are explicitly not trying to solve this problem for every free
        OS in the world. </li>
    <li> Changes to the OpenGL API. The definition of OpenGL is
        controlled by the OpenGL Architecture Review Board, and we in no
        way challenge this. A single GLX extension is required; this
        extension has already been approved by the ARB. </li>
    <li> Use of 3D outside the X11/GLX context. There are a variety of
        approaches (fxMesa, GGI, etc.) that again are welcome to use
        relevant parts of this project, but whose support is not part of
        its goals. </li>
    </ul>

<p> 1.3. We believe all critical decisions have been made. Some
    remaining comments (previously identified as open issues) of
    interest are identified in the <a href="#app">appendix</a>. We
    recognize that some decisions are largely arbitrary (filenames and
    file locations, for example) and in those cases have been guided by
    existing practice (<i>in other words, complaining about arbitrary
    decisions is unlikely to change them</i>). </p>

<p> 1.4. Participants in this effort to date include people working at
    or involved with the following companies and open source projects
    (as well as a large number of individuals with unknown
    affiliations): </p>

    <blockquote>
    3Dfx, Alias/Wavefront, Apple, Avid, Compaq, Debian, HP, IBM, Intel,
    Linux Standard Base, Loki Games, Mesa, Metro Link, NVIDIA, Nichimen,
    Parametric Technology Corporation, Precision Insight, SGI, Sharp
    Eye, Sun, XFree86, Xi Graphics.</blockquote>

<p> <a name="2"></a></p>
<h6>2. Calling Conventions</h6>

<p> 2.1. OpenGL already includes its own datatypes (<tt>GLint,
    GLshort,</tt> etc.) used in the API. Guaranteed minimum sizes are
    stated (see table 2.2 of the OpenGL 1.2 Specification), but the
    actual choice of C datatype is left to the implementation. For our
    purposes, however, all implementations on a given binary
    architecture must have common definitions of these datatypes. </p>

<p> For the IA32 architecture, the definitions should be: </p>

<table border="1" class="center-table">
    <tr><td>GL datatype</td>
        <td>Description</td>
        <td>gcc equivalent for IA32</td></tr>
    <tr><td><tt>GLboolean</tt></td>
        <td>8-bit boolean</td>
        <td><tt>unsigned char</tt></td></tr>
    <tr><td><tt>GLbyte</tt></td>
        <td>signed 8-bit 2's-complement integer</td>
        <td><tt>signed char</tt></td></tr>
    <tr><td><tt>GLubyte</tt></td>
        <td>unsigned 8-bit integer</td>
        <td><tt>unsigned char</tt></td></tr>
    <tr><td><tt>GLshort</tt></td>
        <td>signed 16-bit 2's-complement integer</td>
        <td><tt>short</tt></td></tr>
    <tr><td><tt>GLushort</tt></td>
        <td>unsigned 16-bit integer</td>
        <td><tt>unsigned short</tt></td></tr>
    <tr><td><tt>GLint</tt></td>
        <td>signed 32-bit 2's-complement integer</td>
        <td><tt>int</tt></td></tr>
    <tr><td><tt>GLuint</tt></td>
        <td>unsigned 32-bit integer</td>
        <td><tt>unsigned int</tt></td></tr>
    <tr><td><tt>GLsizei</tt></td>
        <td>non-negative 32-bit binary integer size</td>
        <td><tt>int</tt></td></tr>
    <tr><td><tt>GLenum</tt></td>
        <td>enumerated 32-bit value</td>
        <td><tt>unsigned int</tt></td></tr>
    <tr><td><tt>GLbitfield</tt></td>
        <td>32 bit bitfield</td>
        <td><tt>unsigned int</tt></td></tr>
    <tr><td><tt>GLfloat</tt></td>
        <td>32-bit IEEE754 floating-point</td>
        <td><tt>float</tt></td></tr>
    <tr><td><tt>GLclampf</tt></td>
        <td>Same as GLfloat, but in range [0, 1]</td>
        <td><tt>float</tt></td></tr>
    <tr><td><tt>GLdouble</tt></td>
        <td>64-bit IEEE754 floating-point</td>
        <td><tt>double</tt></td></tr>
    <tr><td><tt>GLclampd</tt></td>
        <td>Same as GLdouble, but in range [0, 1]</td>
        <td><tt>double</tt></td></tr>
</table>

<p> <a href="#issue2.1">Issues</a></p>

<p> 2.2. Assembly-level call conventions must be shared. Since the
    OpenGL implementation may use C++ code internally (e.g. for GLU),
    this is potentially a serious problem. Static linking of C++
    libraries used by OpenGL libraries may be required of the
    implementation (also see the <a href="#3">Libraries</a> section
    below). </p>

<p> <a href="#issue2.2">Issues</a> </p>

<p> <a name="3"></a></p>
<h6>3. Libraries</h6>

<p> 3.1. There are two link-level libraries. <tt>libGL</tt> includes the
    OpenGL and GLX entry points and in general depends on underlying
    hardware and/or X server dependent code that may or may not be
    incorporated into this library. <tt>libGLU</tt> includes the GLU
    utility routines and should be hardware independent, using only the
    OpenGL API. </p>

<p> Each library has two names: the link name used
    on the ld command line, and the <tt>DT_SONAME</tt> within that
    library (specified by the <i>-soname</i> switch when linking the
    library), defining where it's looked up at runtime. Both forms must
    exist so that both linking and running will operate properly. The
    library names are: </p>

<table cellspacing="1" border="1" class="center-table">
    <tr><td>Link name</td>
        <td>Runtime name (<tt>DT_SONAME</tt>)</td>
    </tr>
    <tr><td><tt>libGL.so<tt></td>
        <td><tt>libGL.so.1<tt></td>
    </tr>
    <tr><td><tt>libGLU.so<tt></td>
        <td><tt>libGLU.so.1<tt></td>
    </tr>
</table>

<p> <tt>libGL.so</tt> and <tt>libGLU.so</tt> should
    be symbolic links pointing to the runtime names, so that
    future versions of the standard can be implemented transparently
    to applications by changing the link. </p>

<p> <a href="#issue3.1">Issues</a> </p>

<p> 3.2. These libraries must be located in <tt>/usr/lib</tt>. The
    X-specific library direction (<tt>/usr/lib/X11</tt>) was also
    considered, but existing practice on Linux and other platforms
    indicates that <tt>/usr/lib</tt> is preferable. </p>

<p> <a href="#issue3.2">Issues</a>

<p> 3.3. C++ runtime environments are likely to be incompatible
    cross-platform, including both the standard C++ library location and
    entry points, and the semantics of issues such as static
    constructors and destructors. The LSB apparently mandates static
    linking of libraries which aren't already in LSB, but this could
    lead to problems with multiple C++ RTLs present in the same app
    using C++. We'll have to tread carefully here until this issue
    is more completely understood. </p>

<p> <a href="#issue3.3">Issues</a> </p>

<p> 3.4. The libraries must export all OpenGL 1.2,
    GLU 1.3, GLX 1.3, and <tt>ARB_multitexture</tt> entry points
    statically. </p>

<p> It's possible (but unlikely) that additional ARB or vendor
    extensions will be mandated before the ABI is finalized.
    Applications should not expect to link statically against any entry
    points not specified here. </p>

<p> 3.5. Because non-ARB extensions vary so widely and are constantly
    increasing in number, it's infeasible to require that they all be
    supported, and extensions can always be added to hardware drivers
    after the base link libraries are released. These drivers are
    dynamically loaded by <tt>libGL</tt>, so extensions not in the base
    library must also be obtained dynamically. </p>

<p> 3.6. To perform the dynamic query,
    <tt>libGL</tt> also must export an entry point called </p>

    <blockquote>
        <tt>void (*glXGetProcAddressARB(const GLubyte *))();</tt>
    </blockquote>

<p> The <a href="http://www.opengl.org/registry/specs/ARB/get_proc_address.txt">full specification</a>
    of this function is available separately. It takes the string name
    of a GL or GLX entry point and returns a pointer to a function
    implementing that entry point. It is functionally identical to the
    <tt>wglGetProcAddress</tt> query defined by the Windows OpenGL
    library, except that the function pointers returned are <i>context
    independent</i>, unlike the WGL query. </p>

<p> All OpenGL and GLX entry points may be queried with this extension;
    GLU extensions cannot, because GLU is a client-side library that
    cannot easily be extended. </p>

<p> <a href="#issue3.6">Issues</a> </p>

<p> 3.7. Thread safety (the ability to issue OpenGL calls to different
    graphics contexts from different application threads) is required.
    Multithreaded applications must use <b>-lpthread</b>. </p>

<p> 3.8. <tt>libGL</tt> and <tt>libGLU</tt> must be
    transitively linked with any libraries they require in their own
    internal implementation, so that applications don't fail on some
    implementations due to not pulling in libraries needed not by the
    app, but by the implementation. </p>

<p> <a name="4"></a></p>
<h6>4. Header Files</h6>

<p> 4.1. The following header files are required: </p>

    <ul>
    <li> <tt>&lt;GL/gl.h&gt;</tt> - OpenGL </li>
    <li> <tt>&lt;GL/glx.h&gt;</tt> - GLX </li>
    <li> <tt>&lt;GL/glu.h&gt;</tt> - GLU </li>
    <li> <tt>&lt;GL/glext.h&gt;</tt> - OpenGL Extensions </li>
    <li> <tt>&lt;GL/glxext.h&gt;</tt> - GLX Extensions </li>
    </ul>

<p> These headers should properly define prototypes and enumerants for
    use by applications written in either C or C++. Other language
    bindings are not addressed at this time. </p>

<p> 4.2. These header files must be located in <tt>/usr/include/GL</tt>.
    <tt>/usr/include/X11/GL</tt> was considered and rejected for the
    same reasons as library locations in section 3.2 above. </p>

<p> 4.3. The required headers must not pull in
    internal headers or headers from other packages where that would
    cause unexpected namespace pollution (for example, on IRIX
    <tt>glx.h</tt> pulls in <tt>&lt;X11/Xmd.h&gt;</tt>). Likewise the
    required headers must be protected against multiple inclusion and
    should not themselves include any headers that are not so protected.
    However, <tt>glx.h</tt> is allowed to include
    <tt>&lt;X11/Xlib.h&gt;</tt> and <tt>&lt;X11/Xutil.h&gt;</tt>. </p>

<p> 4.4. <tt>glx.h</tt> must include the prototype of the
    <tt>glXGetProcAddressARB</tt> extension described above. </p>

<p> 4.5. All OpenGL 1.2 and <tt>ARB_multitexture</tt>, GLU 1.3, and GLX
    1.3 entry points and enumerants must be present in the corresponding
    header files <tt>gl.h</tt>, <tt>glu.h</tt>, and <tt>glx.h</tt>,
    <b>even if</b> only OpenGL 1.1 is implemented at runtime by the
    associated runtime libraries. </p>

<p> <a href="#issue4.5">Issues</a> </p>

<p> 4.6. Non-ARB OpenGL extensions are
    defined in <tt>glext.h</tt>, and non-ARB GLX extensions in
    <tt>glxext.h</tt>. If these extensions are also defined in one of
    the other required headers, this must be done conditionally so that
    multiple definition problems don't occur. </p>

<p> <a href="#issue4.6">Issues</a> </p>

<p> 4.7. Vendor-specific shortcuts, such as macros for higher
    performance GL entry points, are intrinsically unportable. These
    should <b>not</b> be present in the required header files, but
    instead in a vendor-specific header file that requires explicit
    effort to access, such as defining a vendor-specific preprocessor
    symbol. Likewise vendors who are not willing to include their
    extensions in <tt>glext.h</tt> must isolate those extensions in
    vendor-specific headers. </p>

<p> 4.8. <tt>gl.h</tt> must define the symbol
    <tt>GL_OGLBASE_VERSION</tt>. This symbol must be an integer defining
    the version of the ABI supported by the headers. Its value is
    <i>1000 * major_version + minor_version</i> where
    <i>major_version</i> and <i>minor_version</i> are the major and
    minor revision numbers of this ABI standard. The primary purpose of
    the symbol is to provide a compile-time test by which application
    code knows whether the ABI guarantees are in force. </p>

<p> <a href="#issue4.8">Issues</a> </p>

<p> <a name="5"></a></p>
<h6>5. Extension Headers</h6>

<p> 5.1. Providing prototypes and enumerants for OpenGL extensions is
    challenging because of the expected wide variety of hardware
    drivers, continuing creation of extensions, and multiple sources of
    header files on Linux OpenGL implementations. Some extensions will
    be supported only for a specific implementation, and some will be
    supported only for a specific hardware driver within that
    implementation. This situation does not lend itself easily to
    independent maintenance of header files definining the extensions.
    </p>

<p> Instead, we require a single header file defining <b>all</b> OpenGL
    extensions be supplied from a central point and updated on a
    continuing basis as new extensions are added to the OpenGL <a
    href="http://www.opengl.org/registry/">extension registry</a> (which
    is similarly centrally maintained). The central point is in the
    registry at <a href="http://www.opengl.org/registry/">
    http://www.opengl.org/registry/</a>. </p>

<p> The <a href="../api/GL/glext.h">latest version of
    <tt>glext.h</tt></a> is available in the registry. It is
    automatically generated from the master OpenGL function and
    enumerant registries, and is updated as new extensions are
    registered. The header is intended to be useful on other platforms
    than Linux, particularly Windows; please let us know (via feedback
    to OpenGL.org forums) if it needs enhancement for use on another
    platform. The generator scripts and &quot;.spec&quot; files used in
    generating glext.h are also available. </p>

<p> Likewise for GLX, a single header defining
    all GLX extensions, <a href="../api/GL/glxext.h"><tt>glxext.h</tt></a>,
    is required and is maintained centrally. </p>

<p> The registry also contains a header defining WGL
    extensions, <a href="../api/GL/wglext.h"><tt>wglext.h</tt></a>, but this is
    only for use on Windows; <tt>wglext.h</tt> is <b>not</b> required by
    or useful for the Linux ABI. </p>

<p> <a href="#issue5.1">Issues</a> </p>

<p> 5.2. The centrally maintained <tt>glext.h</tt> will be continually
    updated, so version creep is expected. This could cause problems for
    open source projects distributing source code. The proper solution
    is for users to update glext.h to the latest version, but versioning
    has proven helpful with other extensible aspects of OpenGL.
    Therefore <tt>glext.h</tt> must include a preprocessor version
    symbol <tt>GL_GLEXT_VERSION</tt>, enabling apps to do something
    like: </p>

<blockquote>
    <tt>
    #include &lt;GL/glext.h&gt;<br>
    #if GL_GLEXT_VERSION &lt; 42<br>
    #error "I need a newer &lt;GL/glext.h&gt;. Please download it from http://www.opengl.org/registry/ABI/"<br>
    #endif
    </tt>
</blockquote>

<p> <a href="#issue5.2">Issues</a> </p>

<p> 5.3. Only extensions whose fully documented specifications have been
    made available to the extension registry and whose authors have
    committed to shipping them in their drivers will be included in
    <tt>glext.h</tt> and <tt>glxext.h</tt>. The structure of each
    extension defined in these headers should resemble: </p>

<blockquote>
    <tt>
    #ifndef GL_EXT_<i>extensionname</i><br>
    #define GL_EXT_<i>extensionname</i> 1<br>
    <i> Define enumerants specific to this extension</i><br>
    <i> Typedef function pointers for entry points specifically to
        this extension, dynamically obtained
        with glXGetProcAddressARB</i><br>
    #ifdef GL_GLEXT_PROTOTYPES<br>
    <i> Define prototypes specific to this extension</i><br>
    #endif<br>
    #endif
    </tt>
</blockquote>

<p> Benign redefinition of the enumerants is allowable, so these may be
    outside protective <tt>#ifndef</tt> statements (this structure
    results from the generator scripts used in the OpenGL SI to build
    <tt>glext.h</tt>, and also because some enums may be defined by
    multiple different extensions, so it could make sense to segregate
    them). </p>

<p> Function pointer typedefs will use the Windows convention (e.g. the
    typedef for a function <tt>glFooARB</tt> will be
    <tt>PFNGLFOOARBPROC</tt>) for application source code portability.
    </p>

<p> Normally, prototypes are present in
    the header files, but are not visible due to conditional compilation.
    To define prototypes as well as typedefs, the application must
    <tt>#define GL_GLEXT_PROTOTYPES</tt> prior to including
    <tt>gl.h</tt> or <tt>glx.h</tt>. <i>(Note: consistency suggests
    using <tt>GLX_GLXEXT_PROTOTYPES</tt> for <tt>glxext.h</tt> -
    TBD)</i>. </p>

<p> The preprocessor symbol protecting the extension declaration
    must be the same as the name string identifying the extension at
    runtime and in the extension registry. </p>

<p> <b>All</b> OpenGL and GLX extensions that are shipping should have a
    full extension specification in the master
    <a href="http://www.opengl.org/registry">
    extension registry</a> on www.opengl.org. Vendors failing to document
    and specify their on extensions will not be allowed to incorporate
    the resulting inadequate interfaces into the ABI. </p>

<p> <a href="#issue5.3">Issues</a> </p>

<p> 5.4. <tt>glext.h</tt> is normally
    <tt>#include</tt>ed by <tt>gl.h</tt>. This inclusion can be
    suppressed by the application defining the preprocessor symbol
    <tt>GL_GLEXT_LEGACY</tt> prior to its <tt>#include
    &lt;GL/gl.h&gt;</tt>. </p>

<p> <img src="new.gif">Similarly, <tt>glxext.h</tt> is normally
    <tt>#include</tt>ed by <tt>glx.h</tt>. This inclusion can be
    suppressed by the application defining the preprocessor symbol
    <tt>GLX_GLXEXT_LEGACY</tt> prior to its <tt>#include
    &lt;GL/glx.h&gt;</tt>. </p>

<p> <a href="#issue5.4">Issues</a> </p>

<p> <a name="6"></a></p>
<h6>6. Feedback and Mailing Lists</h6>

<p> Since the ABI has been finalized, we are no longer maintaining the
    oglbase-discuss mailing list used during its development. List
    archives may still be available from
    <a href="http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/">
    http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/</a> </p>

<hr/>

<p> <a name="app"></a></p>
<h6>Appendix: Open Issues</h6>

<p> <a name="issue2.1"></a>
    <b>Section 2.1</b>:
    Define GL datatypes for other supported Linux architectures - Alpha,
    PowerPC, MIPS, etc. (in general these will be identical to the IA32
    types). Note: we may want to suggest <tt>GLlong</tt> and
    <tt>GLulong</tt> as 64-bit datatypes for future OpenGL revisions. </p>

<p> <a name="issue2.2"></a>
    <b>Section 2.2</b>:
    C++ libraries at runtime can be problematic - take the gcc/egcs
    split, for example. Another potential problem area is static
    constructor/destructor issues, e.g. when a C <tt>main()</tt> is
    linked against GLU. Some tweaking may be required as apps running
    against different ABI revisions start appearing. </p>

<p> <a name="issue3.1"></a>
    <b>Section 3.1</b>:
    LSB uses a more complex naming convention for libraries; we're
    avoiding this at least for now, because these conventions disagree
    with common practice on virtually all other Unix OpenGL
    implementations. </p>

<p> <a name="issue3.2"></a>
    <b>Section 3.2 (also Section 4.1)</b>:
    Placing the headers and libraries in non-X11 specific locations
    could impact non-GLX OpenGL implementations resident on the same
    platform. It is also somewhat out of keeping with other X
    extensions. However, this practice is so common on other platforms,
    and non-X based OpenGL implementations are so rarely used, that we
    chose to do so for build portability and "principle of least
    surprise" purposes. </p>

<p> Nothing prohibits the implementation from
    placing the actual library files in other locations and implementing
    the required library paths as links. </p>

<p> <a name="issue3.3"></a>
    <b>Section 3.3</b>:
    The ABI should probably state requirements on GL libraries using C++
    or other auxiliary libraries, such that no conflict will arise with
    apps also using those libraries. </p>

<p> <a name="issue3.6"></a>
    <b>Section 3.6</b>:
    The context-independence requirement was the subject of enormous
    controversy, mostly because the consequences of this requirement on
    the underlying link library and driver implementations can be
    significant. It is impossible to briefly recap the many pro and con
    arguments briefly; refer to the <a href="#6">mailing list
    archive</a> to learn more. </p>

<p> GLU does sometimes need to be extended to
    properly support new GL extensions; in particular, new pixel formats
    and types, or new targets for texture downloads, such as cube
    mapping, should ideally be exposed through the GLU mipmap generation
    routines. This is an unresolved problem, since GLU is client code
    not specific to any GL driver and thus not dynamically loadable. The
    best current option is for driver suppliers to make sure that
    whatever GLU functionality they need is contributed to the OpenGL
    Sample Implementation's GLU library. </p>

<p> Portable applications should treat the pointers
    as context-dependent. </p>

<p> We haven't determined if any non-ARB extensions should be standard
    entry points not requiring this dynamic lookup. As a reference
    point, here are lists of GL, GLX, and GLU extensions supported by a
    variety of OpenGL and Mesa implementations today (please send
    additions for other platforms to the oglbase-discuss mailing list so
    they can be added): </p>

    <ul>
    <li><a href="ext/3dlabs.txt">3Dlabs</a> </li>
    <li><a href="ext/compaq.txt">Compaq</a> </li>
    <li><a href="ext/intergraph.txt">Intergraph/Intense 3D</a> </li>
    <li><a href="ext/mesa.txt">Mesa</a> </li>
    <li><a href="ext/sgi.txt">SGI (multiple platforms)</a> </li>
    <li><a href="ext/sun_ultra.txt">Sun Ultra</a> </li>
    <li><a href="ext/xig.txt">Xi Graphics</a> </li>
    </ul>

<p> <a name="issue4.5"></a>
    <b>Section 4.5</b>:
    Implementations may still implement only OpenGL 1.1 functionality,
    but the 1.2 header and link library material must still be provided.
    Since applications must already check both compile and runtime
    OpenGL version numbers, no problems due to lacking support for 1.2
    are expected. The next version of this standard is anticipated to
    require OpenGL 1.2 support. </p>

<p> <a name="issue4.6"></a>
    <b>Section 4.6</b>:
    It's important that <tt>glext.h</tt> and <tt>glxext.h</tt> can be
    updated from the extension registry without breaking <tt>gl.h</tt>
    and <tt>glx.h</tt>. Making sure that all extension definitions are
    properly protected helps to this end, as well as being good
    programming practice. </p>

<p> <a name="issue4.8"></a>
    <b>Section 4.8</b>:
    <tt>GL_OGLBASE_VERSION</tt> is mostly provided so that apps can
    determine whether to use traditional static linking of extensions,
    or to dynamically query them. Unlike GL/GLX versioning, the ABI
    version is not dynamically queryable at runtime. Historical
    experience suggests that not providing the runtime query to begin
    with is a bad decision. </p>

<p> <a name="issue5.1"></a>
    <b>Section 5.1</b>:
    <tt>glext.h</tt> is an exception to the Linux-centric nature of this
    document, since it is already being used on other platforms. </p>

<p> <a name="issue5.2"></a>
    <b>Section 5.2</b>:
    Applications should <b>not</b> use the version number in
    <tt>glext.h</tt> to test for presence or absence of specific
    extension prototypes; this is extremely unportable and dangerous.
    Always use the extension-specific symbols described in section 5.3.
    </p>

<p> The header version symbol was changed from
    <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt> for
    consistency with the <tt>GLEXT</tt> namespace the ABI group has
    started using. </p>

<p> <a name="issue5.3"></a>
    <b>Section 5.3</b>:
    Other structures for the extension prototypes have been suggested,
    such as having separate header files for each extension. Having both
    structures may be preferable, but it requires more work. </p>

<p> <a name="issue5.4"></a>
    <b>Section 5.4</b>:
    It's important to be able to suppress automatic inclusion of
    <tt>glext.h</tt> and <tt>glxext.h</tt> in order to support
    compilation of legacy code not written to be ABI-aware (e.g.
    assuming that extensions can be statically linked). </p>

<p> <a name="log"></a></p>
<h6>7. Change Log</h6>

<ul>
<li> 10/9/2006 - updated registry links to the new location on
     opengl.org and cleaned up other dangling wording due to the move
     from oss.sgi.com.
<li> 6/20/2000 (version 1.0) - Linux ABI approved on the oglbase-discuss
     mailing list. Corrected Windows function-pointer typedef convention
     in section 5.3 by appending <tt>PROC</tt>, to match what glext.h
     already does. </li>
<li> 5/29/2000 (version 0.9.8) - <tt>glxext.h</tt> added to section 4.
     Resolution reached on the structure of <tt>glext.h</tt> and
     <tt>glxext.h</tt>, and how they are included from <tt>gl.h</tt> and
     <tt>glx.h</tt>. In particular, <tt>GL_OGLBASE_VERSION</tt> symbol
     defined, default inclusion of extension headers from core headers
     mandated, <tt>GL_GLEXT_PROTOTYPES</tt> may be specified in order to
     get extension prototypes as well as function pointer typedefs.
     Renamed <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt>.
     </li>
<li> 4/9/2000 (version 0.9.7) - <tt>glext.h</tt> is now available
     together with the ABI specification. </li>
<li> 2/22/2000 (version 0.9.6) - Revised for public comment period.
     Moved open issues to the new appendix. </li>
<li> 2/8/2000 (version 0.9.5) - Removed ellipses from prototype in
     section 3.6, and simplified the lists of SGI supported extensions
     into one file. Mandated threadsafety in section 3.7. Moved
     glXGetProcAddressARB prototype from gl.h to glx.h in section 4.4,
     since the function itself was moved from gl to glX during
     standardization. Restructured the page to fit into the ogl-sample
     site on oss.sgi.com, next to the extension registry. Pointed to the
     updated extension registry on oss.sgi.com in several places. </li>
<li> 12/9/99 (version 0.9.4) - Added Intergraph extension list in
     section 3.6. </li>
<li> 12/6/99 (version 0.9.3) - Added Compaq and 3Dlabs extension
     lists in section 3.6. </li>
<li> 11/23/99 (version 0.9.2) - Refined discussion of
     glXGetProcAddressARB to specify that any GL or GLX function can be
     queried. </li>
<li> 11/23/99 (version 0.9.1) - Summing up lots of email discussion.
     Expanded participant list in section 1.4. Pinned down library
     naming scheme in section 3.1. Changed to require statically
     exporting all GL 1.2 / GLX 1.3 / GLU 1.3 / ARB extension entry
     points in section 3.4. Changed GetProcAddress from EXT to ARB and
     from gl to glX(in anticipation of ARB approval) in section 3.5.
     Does <b>not</b> require a context parameter. Require Windows naming
     convention for <tt>glext.h</tt> function prototypes in section 5.3.
     Added a link to the list archives in section 6. </li>
<li> 9/16/1999 - Added Mesa, Sun, and Xi Graphics extension lists in
     section 3.6. Added section 3.8 on transitive library dependencies
     of the GL libraries. </li>
<li> 9/10/1999 - Added initial list of GL/GLX/GLU extensions
     for existing platforms in section 3.6.<br>
     Specified text/link colors as well as background color. </li>
<li> 9/7/1999 - Initial version. </li>
</ul>

<?php include_once("../../../assets/static_pages/khr_page_bottom.php"); ?>
</body>
</html>