libglapi.so, libGL.so, libGLESv2.so, libGLESv1_CM.so must all
come from the same version of Mesa or bad things may happen.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
glapioffsets.h exists for the same reason as glapidispatch.h does. It
is of no use to glapi. This commit also drops the use of glapioffsets.h
in glx as glx is considered an extension to glapi when it comes to
defining public GL entries.
glapidispatch.h exists so that core mesa (libmesa.a) can be built for
DRI drivers or for non-DRI drivers as a compile time decision (whether
IN_DRI_DRIVER is defined). It is of no use to glapi. This commit also
drops the use of glapidispatch.h in glx and libgl-xlib as they are
considered extensions to glapi when it comes to defining public GL
entries.
