Re: [Mesa-dev] Stable libEGL ABI ?
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
Re: [Mesa-dev] Stable libEGL ABI ?
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
[Mesa-dev] Stable libEGL ABI ?
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
