According to the EGL spec, eglGetProcAddress should only be used to
retrieve extension functions. It also says that returning non-NULL
does not mean the extension is available so you could interpret this
as saying that the function is allowed to return garbage for core
functions. This seems to happen at least for the Android
implementation of EGL.
To workaround this the winsys's are now passed down a flag to say
whether the function is from the core API. This information is already
in the gl-prototypes headers as the minimum core GL version and as a
pair of flags to specify whether it is available in core GLES1 and
GLES2. If the function is in core the EGL winsys will now avoid using
eglGetProcAddress and always fallback to querying the library directly
with the GModule API.
The GLX winsys is left alone because glXGetProcAddress apparently
supports querying core API and extension functions.
The WGL winsys could ideally be changed because wglGetProcAddress
should also only be used for extension functions but the situation is
slightly different because WGL considers anything from GL > 1.1 to be
an extension so it would need a bit more information to determine
whether to query the function directly from the library.
The SDL winsys is also left alone because it's not as easy to portably
determine which GL library SDL has chosen to load in order to resolve
the symbols directly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1)
Since we aren't able to break API on the 1.12 branch
cogl_get_proc_address is still supported but isn't easily able to
determine whether the given name corresponds to a core symbol or
not. For now we just assume the symbol being queried isn't part
of the core GL api and update the documentation accordingly.
df77e8565e