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

[Jammy Zhou]

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>