I have a question about the libGL ABI. The "OpenGL Application Binary Interface for Linux" document (http://oss.sgi.com/projects/ogl-sample/ABI/index.html#3) says that only GLX entry points that are required to be static are those in the GLX 1.3 standard. Based on that, I recently (i.e., yesterday) chopped out a bunch of the static entry points for functions that have both "extension" and "core" versions. For example, glXGetCurrentReadDrawableSGI went away, but it is aliased to glXGetCurrentReadDrawable in the GLX_functions table (which is used by glXGetProcAddress).
Is this okay to do?
Hmmm...
Currently, the only functions that are aliased like this are both GLX_SGI_make_current_read functions, a few GLX_SGIX_fbconfig functions, and glXGetCurrentDisplayEXT (from GLX_EXT_import_context and GLX 1.2). Since this last function has been supported for so long in XFree86, it's the only one that I'm at all concerned about. In the future, some of the pbuffers functions may get the same treatment.
I guess I'd like to keep the existing "real" GLX extension functions whenever possible. Some apps/libs (like some varients of GLUT) have direct calls to some GLX functions like glXGetFBConfigAttribSGIX(). If those functions don't exist in libGL people may have problems. I see some reports of this kind of problem with NVIDIA's libGL and older copies of GLUT as-is.
In stand-alone Mesa I also have stubs for quite a few GLX extension functions just to maximize ABI interoperability.
-Brian
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
