[Mesa-dev] Stable libEGL ABI ?

Chad Versace chad.versace at intel.com
Wed May 13 09:46:38 PDT 2015


On Fri 08 May 2015, Emil Velikov wrote:
> Hi all,
> 
> Just had a quick look at Debian's repo and noticed something rather
> worrying - the ABI of our libEGL is not stable.
> Stable in the sense of - we provide a growing list of static symbols
> for each new function an EGL extension adds.
> 
> This comes as we set EGL_EGLEXT_PROTOTYPES, prior to including
> eglext.h. Which in turn exposes the the function prototypes which are
> explicitly annotated with default visibility. This change was
> introduced with
> 
> commit 1ed1027e886980b9b0f48fa6bfcf3d6e209c7787
> Author: Brian Paul <brian.paul at tungstengraphics.com>
> Date:   Tue May 27 13:45:41 2008 -0600
> 
>     assorted changes to compile with new EGL 1.4 headers (untested)
> 
> From going through the EGL 1.3 to 1.5 spec, I cannot see any mention
> that one should export EGL extension functions from their
> implementation. On the contrary, it is explicitly mentioned that some
> implementations may do so, but relying on it in your program is not
> portable. Quick look at the Nvidia official driver shows only core EGL
> functions, which aligns with various "undefined symbol
> eglCreateImageKHR" issues that I've seen not too long ago - mir,
> gstreamer, piglit.
> 
> 
> So the question here is:
> 
> Can we "break" the already non-portable ABI, and hide everything that
> is not core EGL, or alternatively how can we rework things so that as
> we add new entry points, required by extensions, they are available
> only dynamically ?
> 
> Personally I would opt for the former and address any issues in
> piglit/waffle/foo accordingly. I would suspect that libepoxy is OK,
> although I've never looked too closely at the code.
> 
> I would love to get this in some shape or form for 10.6, and avoid
> exporting the two new functions from EGL_MESA_image_dma_buf_export :-\

Me too. As I explained in a previous message [1], I think we should
scrub the non-portable ABI sooner rather than later. I don't consider
this a "break", because it was non-portable all along.

[1] http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg83036.html


More information about the mesa-dev mailing list