On 05/13/2015 04:14 PM, Emil Velikov wrote:
On 13 May 2015 at 17:46, Chad Versace <chad.vers...@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.p...@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


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to