[Mesa-dev] libGL.so and libGLES*.so mess

[Chia-I Wu]

Hi,

With OpenGL ES coming to desktop, the way the current context/dispatch
is stored, together with the way libGLES*.so is created, causes
several issues[1].  The root of these issues is that the symbols
defined in libGL.so and in libGLES*.so overlaps, and an application
might link to both of them indirectly!

In light of GLX_EXT_create_context_es2_profile, the simplest solution
would be to stop distributing libGLES*.so.  Applications will always
link to libGL.so.  Those that use GLX can then call glXGetProcAddress
to get the addresses of OpenGL ES 2.0 functions.  But those that use
EGL will be in trouble.  eglGetProcAddress is defined not to return
the addresses of non-extension functions.

If libGL.so and libGLES*.so both have to be distributed, then the
question becomes how to handle symbols that overlaps gracefully.

Accessing global variables such as _glapi_Context and _glapi_Dispatch
will fail.  Say libGL.so and libGLES*.so both has a copy of
_glapi_Context.  There is no guarantee that GET_CURRENT_CONTEXT will
return the same context set by _glapi_set_context.

Calling global functions will work as long as they are identical in
both libGL.so and libGLES*.so.  This means both libraries must agree
on the order of slots in the dispatch table.  And the problem with two
copies of global _glapi_Dispatch also needs to be solved.

One solution for these issues is to move _glapi_Context,
_glapi_Dispatch, and _glapi_* functions to libglapi.so.  libGL.so and
libGLES*.so will both link to libglapi.so.  All the libraries must be
distributed together, as they must agree on the dispatch table used.
This change should not break the ABI for existing DRI drivers.

Another option is make _glapi_Context and _glapi_Dispatch local.
libGL.so, libGLES*.so, and every DRI driver will get a renamed local
copy of _glapi_Context and _glapi_Dispatch.  To not break the ABI for
old DRI drivers, libGL.so and libGLES*.so will still export
_glapi_Dispatch and _glapi_Context.  But same as the first solution,
there must be a big dispatch table that libGL.so and libGLES*.so can
agree on.

There should be other options, but these are all I have now.  Any
thought?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=32285

-- 
olv at LunarG.com