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

[Chia-I Wu]

On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou <jammy.zhou at linaro.org> wrote:
> 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[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.
I am curious how other vendors solve this issue.  Or more generally,
how other toolkits solve providing mulitple shared libraries with
overlapping symbols, and that are also supposed to be used altogether.
>>
>> 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.
Or to pick one of the libraries to own libglapi, and have others link to it.
>> 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.
Sorry, this won't work.
>> 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
>
>



-- 
olv at LunarG.com