[Mesa-dev] Stable libEGL ABI ?

[Emil Velikov]

On 13 May 2015 at 17:46, Chad Versace <chad.versace at intel.com> wrote:
> 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.
>
Thanks for the review and confirmation Chad. That's precisely why I
placed quotes around the word :-)

Brian, I'm planning to push the series that resolves tomorrow
evening(ish). Can you let me know if you have any objections/conserns
prior to that.

Thanks
Emil