If you happened to do both GLES2 and GLES1 in a process, it meant that
you'd try to look up v1 procs in the v2 API, and lose. Caught by
piglit oes_fixed_point-attribute-arrays.
The new linker requires that the consumers of a library link against
the libraries that that library depends on, which is supported by
Libs.private.
Fixes#16
We can't completely avoid it, since gl's headers use these defines for
their header guards, and we really do need to stop the system GL
headers from doing anything.
Fixes#14
It's been 0x000fffff on Mesa since the initial import in 1999. It's
the same value on my OS X 10.8 system, mingw's Windows-compatible
gl.h, and a copy of the windows SDK gl.h I found laying around on the
internet.
Fixes piglit ARB_multisample/pushpop.
EGL_KHR_image_base defines these two functions, and so does
EGL_KHR_image (which is bascically the union of EGL_KHR_image_base and
EGL_KHR_image_pixmap).
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
This lets the compiler generate faster function calls (call through
function pointer, instead of call into a linker-generated stub func
containing jump to function pointer).
For example, on desktop 2.1 GL on Apple, there's no glBindVertexArray,
but there is glBindVertexArrayAPPLE, and as far as a caller is
concerned, the APPLE variant should be able to stand in for the
core/ARB version. Similarly for trying to do FBOs on an old Mesa
implementation that didn't have ARB_fbo yet, but did have EXT_fbo.
When initially writing the Makefiles, I started from a Makefile.am
that had ajax's copyright instead of an Intel one. The only line I
can see that's left from the original Makefile.am is "pkgconfigdir" in
the root Makefile.am.
For a non-GLX application, at least, we need to pull our extensions
using dlsym, not glXGetProcAddress(). The symptom was a segfault in
glXGetProcAddress().
In addition to the failing testcase, there were a couple of
regressions in piglit's attribs test: one from glBegin_unwrapped vs
glBegin confusion in the __asm__ directives we were generating, and
one where the function pointers apparently were just getting mixed up
at application runtime.
For the dynamically-linked tests, it wasn't a big deal because the
updated library was always picked up. But for glx_static, we were
actually testing stale code.
On OS X, GLhandleARB is void *, which is of different size than GLuint
on 64-bit. Because of this, the implementation of
glGetAttachedObjectsARB must be different from glGetAttachedShaders,
since the pointers/ints are packed the output memory.
Eric Anholt