[Mesa-stable] [Mesa-dev] [PATCH] mapi: Export all GLES 3.1 functions in libGLESv2.so
Chad Versace
chad.versace at intel.com
Fri Jun 24 18:35:20 UTC 2016
On Thu 23 Jun 2016, Ian Romanick wrote:
> ping
>
> *Before* 12.0 ships, we must either land this patch or a patch that
> redacts the GLES 3.1 functions (e.g., glDispatchCompute) that we already
> statically export.
Pong. Yes, please do this.
Yes, this sucks (for Linux ABI conventions). The alternative also sucks
(violating the EGL spec).
In my opinion, since we (the Mesa devs) haven't yet solved the ABI
problem despite having a LONG time to do so, we need to admit that we
failed to do it in a timely manner and just move forward with what the
EGL spec requires: export all the core symbols. *After* our libGLEsv2 is
conformant, then we can start planning how to prevent future ABI
mistakes.
Acked-by: Chad Versace <chad.versace at intel.com>
> On 06/17/2016 10:20 AM, Ian Romanick wrote:
> > From: Ian Romanick <ian.d.romanick at intel.com>
> >
> > Khronos recommends that the GLES 3.1 library also be called libGLESv2.
> > It also requires that functions be statically linkable from that
> > library.
> >
> > NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension
> > since at least Mesa 10.5, so applications targeting Linux should use
> > eglGetProcAddress to avoid problems running binaries on systems with
> > older, non-GLES 3.1 libGLESv2 libraries.
> >
> > Signed-off-by: Ian Romanick <ian.d.romanick at intel.com>
> > Cc: "11.2 12.0" <mesa-stable at lists.freedesktop.org>
> > Cc: Mike Gorchak <mike.gorchak.qnx at gmail.com>
> > Reported-by: Mike Gorchak <mike.gorchak.qnx at gmail.com>
> > ---
> > src/mapi/glapi/gen/static_data.py | 51 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
More information about the mesa-stable
mailing list