[Mesa-dev] libGL.so and libGLES*.so mess
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:
> 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. 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
>  https://bugs.freedesktop.org/show_bug.cgi?id=32285
> olv at LunarG.com
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev