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 an improvement?
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 show stopper.
In summary, having the ability of using a shared glapi sounds great, but forcing shared glapi everywhere, sounds a bad idea.
Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
