I am back at this issue with a second try
http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi
In a nutshell, this branch introduces a new configure option,
--enable-shared-glapi. By default it is disabled and things work as
before. But when it is enabled, all except one (more on this below)
_glapi_* symbols are removed from libGL.so, libGLESv1_CM.so, and
libGLESv2.so. There is going to be libGLAPI.so that provides these
symbols, and these libraries simply link to the new library. libGL.so
loads DRI drivers well with or without shared glapi.
Having a shared glapi fixes OpenGL, GLES 1.1, and GLES 2.0
interoperation, as is supported by other OpenGL ES stacks.
The one symbol that is not moved to libGLAPI.so is
_glapi_get_proc_address. If you take a look at glapi on master, you
will notice that while libglapi.a provides _glapi_get_proc_address to
look up any OpenGL function recognized, not all of the functions are
defined by libglapi.a. When functions are promoted from extension to
core, some of them, such as glGenTexturesEXT, are given different GLX
opcodes. Since glGenTextures and glGenTexturesEXT have already been
assigned the same dispatch offset, to differentiate them, the latter
cannot be defined in libglapi.a. It is instead defined in
src/glx/indirect.c.
When shared glapi is enabled, libGLAPI.so cannot correctly define
glGenTexturesEXT, nor can it support
_glapi_get_proc_address("glGenTexturesEXT"). The solution is for
libGLAPI.so to rename _glapi_get_proc_address and for the other
libraries to define their own versions of _glapi_get_proc_address.
This gives libGL.so a chance to properly support glGenTexturesEXT.
This mechanism is implemented by
7a6370b mapi: Fix bridge mode fo GLX.
In my first try, there was no libGLAPI.so (_glapi_* still in libGL.so)
and libGLES* linked to libGL.so. That was chose for this very reason.
But that choice made libGLES* depend on libGL.so, which in turn
brought in X11 dependencies. That was not considered a good move and
thus this second try with shared glapi opt-out.
--
o...@lunarg.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
