[Mesa-stable] [PATCH] mapi: Export all GLES 3.1 functions in libGLESv2.so

[Ian Romanick]

On 06/17/2016 11:15 AM, Emil Velikov wrote:
> On 17 June 2016 at 18:20, Ian Romanick <idr at freedesktop.org> wrote:
>> From: Ian Romanick <ian.d.romanick at intel.com>
>>
>> Khronos recommends that the GLES 3.1 library also be called libGLESv2.
>> It also requires that functions be statically linkable from that
>> library.
>>
>> NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension
>> since at least Mesa 10.5, so applications targeting Linux should use
>> eglGetProcAddress to avoid problems running binaries on systems with
>> older, non-GLES 3.1 libGLESv2 libraries.
>>
> Fwiw I'm inclined that we should go the "opposite direction". Namely:
> don't expose new symbols and stick to a predefined version (3.0 being
> the personal favour of choice).
> 
> Why, you might ask - for a couple of reasons:
>  - If the list continues to grow programs will have unstable ABI -
> sort of how libGL ended up. Applications are going to link against 3.1
> or later symbols [1], even if they only optionally use them. Thus
> things will quite hairy and fragile.

There are at least two solutions, and piglit uses both.  If use of a set
of functions is optional, you can still use GetProcAddress (when
EGL_KHR_get_all_proc_addresses is available) or you can use dlsym.

For me, piglit is where this whole problem actually started.  Right now,
piglit follows the (unextended) rules and does not attempt to use
GetProcAddress on core functions.  It uses dlsym.  I tried to extend
shader_runner for separate shader objects on GLES.  Guess what?  Since
the symbols aren't exported by the library, it didn't work.  So... now
piglit would need TWO code paths... one that uses dlsym and one that
uses eglGetProcAddress... or require an optional extension.

If an application requires GLES 3.1 symbols, it should just be able to
link with them.  As far as I can tell, that's how it works on Android.

>  - The other desktop GLES* provider NVIDIA does not export even a
> single GLES 3.1/3.2 entry point (still going through the 3.0 list) in
> their libGLESv2.so.2 binary.
> 
> So what to do with GLES (3.0?)/3.1 and later:
>  - tweak the spec so that said version of the API is only supported if
> the implementation can get core symbols via eglGetProcAddress. Be that
> props to the EGL_KHR_get_all_proc_addresses extension or EGL 1.5 [2].
> 
> How does this sound ? I guess the best way would be to check with
> other implementations (note Catalyst still seems to be missing
> libGLES*) and choose the more common route ?
> 
> 
> Regards,
> Emil
> 
> [1] Yes, in practise they should use libepoxy or a similar library,
> but from practise we all know that even those tend to have bugs. Sadly
> libepoxy in particular hasn't seen much action in a while.
> 
> [2] https://github.com/anholt/libepoxy/issues/21
> _______________________________________________
> mesa-stable mailing list
> mesa-stable at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable