1. Overview and Goals

1.1. This document is intended to solve two related problems. First, defining the ABI and runtime environment for 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.

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

2. Calling Conventions

2.1. OpenGL already includes its own datatypes (GLint, GLshort, etc.) used in the API. Guaranteed minimum sizes are stated (see table 2.2 of the OpenGL 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.

For the IA32 architecture, the definitions should be:

3.1. There are two link-level libraries. libGL 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. libGLU includes the GLU utility routines and in general is hardware independent, using only the OpenGL API. Exact names of these libraries may vary depending on the underlying OpenGL version supported and on external naming conventions; for example, the LSB uses the convention libfoo.lsb.N where the lsb.N reflects the version of LSB in use. However, it's not clear we should be tied to a particular version of LSB.

Using non-LSB conventions, the library names proposed are:

• OpenGL 1.1 and GLU 1.2: libGL.so.1.1 and libGLU.so.1.2
• OpenGL 1.2 and GLU 1.3: libGL.so.1.2 and libGLU.so.1.3

In either case, libGL.so and libGLU.so would be symbolic links pointing to the most recent installed version of the libraries.

Using LSB conventions, the library names proposed are:

• OpenGL 1.1 and GLU 1.2: libGL.1.1.lsb.N and libGLU.1.2.lsb.N
• OpenGL 1.2 and GLU 1.3: libGL.1.2.lsb.N and libGLU.1.3.lsb.N

3.2. The libraries should be located in /usr/lib. /usr/lib/X11 or another X-specific location was considered, but existing practice on Linux and other platforms indicates that /usr/lib is preferable.
Note: This is a somewhat out of keeping with other X extensions, and driven by existing practice. This location could present some issues in having both X and non-X OpenGL implementations resident on the same platform.

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++.
Open Issue: State requirements on GL libraries using C++ or other auxiliary libraries such that they won't interfere with apps also using those libraries.

3.4. Entry points supported by these libraries must include either of:

• All OpenGL 1.1, GLU 1.2, and GLX 1.2 entry points
• All OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture entry points

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 libGL, so extensions not in the base library must also be obtained dynamically. We thus require that libGL also export an entry point notionally called

void (*glGetProcAddressEXT(GLubyte *))(...);

3.6. This function takes the string name of an extension entry point and returns a pointer to that entry point appropriate to the driver whose context is current. It is functionally identical to the wglGetProcAddress function supplied by the Windows OpenGL library.
Open Issue: Determine what non-ARB extensions, if any, should be standard entry points not requiring this dynamic lookup.

4.1. The following header files are required:

• - OpenGL
• - GLX
• - GLU
• - Extensions

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.
Note: This may present some issues in having both X and non-X OpenGL implementations resident on the same platform.

4.2. The header files must be located in /usr/include/GL. /usr/include/X11/GL was considered and rejected in the same fashion as library locations in section 3.2 above.

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 glx.h pulls in ). Likewise the required headers must be protected against multiple inclusion and should not themselves include any headers that are not so protected.

4.4. gl.h should include the prototype of the glGetProcAddressEXT extension described above.
Open Issues: Define the exact prototype and write the GL extension specification for it.
Should this really be a GL extension? It was previously put in GLX but doesn't really belong there, either, because it's a metafunction returning information about GL and GLX. It's intended to allow access to all driver entry points, but will need to be found in libGL since that's where dynamic driver loading will typically happen. An alternative is to create a new GL namespace and call the query e.g. glextGetProcAddress() and the header file version number (see section 5.2) GLEXT_VERSION.

4.5. All OpenGL 1.2 and ARB_multitexture, GLU 1.3, and GLX 1.3 entry points and enumerants must be present in the corresponding header files gl.h, glu.h, and glx.h, even if only OpenGL 1.1 is provided by the associated runtime libraries.
Note: This requirement anticipates wide availability of OpenGL 1.2 capable hardware and drivers, easing writing apps for them today. Since applications should already check both compile and runtime OpenGL version numbers, no problems due to lacking support for 1.2 are expected.

4.6. Non-ARB extensions are in general to be defined in glext.h. If they are also defined in one of the other required headers, this must be done conditionally so that multiple definition problems don't occur.

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 source base, such as Mesa, and some will be supported only for a specific hardware driver. This situation does not lend itself easily to independent maintenance of header files definining the extensions.

A mailing list has been created for further discussion and finalization of this proposal. We particularly welcome participation by ISVs writing OpenGL-based applications on Linux and IHVs writing OpenGL drivers on Linux.

To initially subscribe to the list, send a message with body

subscribe oglbase-discuss