[Mesa-dev] Stable libEGL ABI ?

Brian Paul brianp at vmware.com
Wed May 13 15:19:55 PDT 2015


On 05/13/2015 04:14 PM, Emil Velikov wrote:
> 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.

I haven't touched EGL in years so whatever you guys think is best is 
fine with me.

-Brian




More information about the mesa-dev mailing list