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

Jammy Zhou jammy.zhou at linaro.org
Fri Dec 10 00:01:36 PST 2010

On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu <olvaffe at gmail.com> wrote:

> 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.

I don't think it is a good solution to stop distributing libGLES*.so,
because in embeded/mobile world, a lot of applications have dependency on
libGLES*.so instead of libGL.so.

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101210/17dbd503/attachment.html>

More information about the mesa-dev mailing list