[Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with
jfonseca at vmware.com
Fri Jun 19 13:26:25 PDT 2015
On 19/06/15 20:56, Emil Velikov wrote:
> Hi all,
> A lovely series inspired (more like 'was awaken to send these out') by
> Pal Rohár, who was having issues when building xlib-libgl (plus the now
> enabled gles*)
> So here, we teach the final two static glapi users about shared-glapi,
> plus some related fixes. After this is done we can finally start
> transitioning to shared-only glapi, with some more details as mentioned
> in one of the patches:
> XXX: With this one done, we can finally transition with enforcing
> shared-glapi, and
> - link the dri modules against libglapi.so, add --no-undefined to
> the LDFLAGS
> - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds
> in the loaders - libGL, libEGL and libgbm.
> - start killing off/cleaning up the dispatch ?
> The caveats:
> 1) up to what stage do we care about static libraries
> - libgl (either dri or xlib based)
> - osmesa
> - libEGL
> 2) how about other platforms (scons) ?
> - currently the scons uses static glapi,
> - would we need the dlopen(...) on windows ?
> Hope everyone is excited about this one as I am :-)
Maybe I missed the context of this changes, but why this matters or is
I understand the rationale for EGL and DRI. But I'm asking specifically
about xlib libgl, osmesa, and Windows ICD drivers.
At a glance, for osmesa and xlib-libgl, forcing to split into multiple
.so seems a step backwards. Rather than making these easy to use and
embedded, it adds complexity, plus potentially prevents using os mesa
and libgl-xlib along side with the system's true libGL.so.
Finally, it's not clear whether this would force Windows OpenGL ICD
drivers to be split into two multiple DLLs, but I'm afraid that's a big
In summary, having the ability of using a shared glapi sounds great, but
forcing shared glapi everywhere, sounds a bad idea.
More information about the mesa-dev