[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
olvaffe at gmail.com
Mon Dec 13 10:12:04 PST 2010
2010/12/13 Kristian Høgsberg <krh at bitplanet.net>:
> On Sun, Dec 12, 2010 at 12:45 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>> 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. 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.
>> I've been working toward this direction. libGL.so will provide
>> _glapi_* symbols as it is now. libGLES*.so will depend on libGL.so
>> instead of providing another copy of _glapi_*. On a x86 machine,
>> libGLESv1_CM.so and libGLESv2.so are down to 17K and 18K in size
>> respectively. The work can be found at
>> Only the last commit is user-visible. It modifies configure.ac to
>> define GLAPI_OWNER, which is the library that owns _glapi_* symbols.
>> It is always $(GL_LIB) unless --disable-opengl is given. When
>> libGLES*.so is built, Makefile will check if libGLES*.so is
>> GLAPI_OWNER and decide whether libGLES*.so should define _glapi_*
>> symbols itself, or use those from GLAPI_OWNER.
> I really don't think this is something we should go out of our way to
> support. It's broken by design, and even if we could fix it with
> library tricks, it's not something any GLES2/GL application could
> depend on, since it would be Mesa specific. And if we do some kind of
> hack to make this work, I don't want libGLESv2 ending up depending on
> libGL.so and all the X dependencies in there. Better to have a shared
> glapi-only type library and then put GLX in a library that links to
> that and make libGLESv2 just a symlink to that. But again, even if we
> do that, linking to both libGL and libGLESv2 isn't going to be widely
> supported, so GL applications and libraries will have to come up with
> their own workarounds anyway or use something like
> I suppose there's no harm in adding this to mesa, but I don't see it
> solving the problem.
Mesa provides libGL.so, libGLESv1_CM.so, and libGLESv2.so. And the
issue here is about applications linking to more than one of these
libraries, not just between libGL.so and libGLESv2.so.
While I am not aware of other stacks that provide both libGL.so and
libGLESv2.so, many mobile devices do provide both libGLESv1_CM.so and
libGLESv2.so. Do linking to both libraries just work? At least it is
a yes on devices based on Android
But it is a NO for Mesa's libGLESv1_CM.so and libGLESv2.so. Even
though this multiple shared libraries idea may be broken by design, it
is implied by EGL and vendors support it sanely. I don't think this
change does not solve the problem.
olv at LunarG.com
More information about the mesa-dev