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