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. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
