A context can create a GLsync object that can be waited on in order
to ensure that GL resources created in one context are able to be
used in another shared context without any chance of reading invalid
data.
This meta would be placed on buffers that are known to cross from
one context to another. The receiving element would then wait
on the sync object to ensure that the data to be used is complete.
If configure finds GL + GLES2 but the user passes --enable-gles2 and
the two GL API's cannot be built against together, configure was still
allowing the desktop GL stack to be built.
Until gcc and GNUStep properly support Objective-C blocks and other
"new" features of Objective-C we can't properly support them without
making the code much more ugly.
https://bugzilla.gnome.org/show_bug.cgi?id=739152
The part of the configure.ac that consist to check if we
can include both GL and GLES2 at the same time is failing.
Indeed, in the case NEED_GLES2=yes and NEED_OPENGL=auto,
HAVE_OPENGL variable is updated whereas it should be HAVE_GL
variable that has to be updated (HAVE_OPENGL variable is not
used in the rest of the configure.ac).
https://bugzilla.gnome.org/show_bug.cgi?id=739348
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin GAIGNARD <benjamin.gaignard@linaro.org>
Replace the hardcoded -lpthread in most of the places with $PTHREAD_LIBS. For
openh264 also add $PTHREAD_LIBS to OPENH264_LIBS until upstream ships a .pc
file.
OpenJPEG 2.0 API uses stdcall on W32 by default. This prevents normal
autoconf library macros from finding its functions.
A more compatible check is to acutally link a program that includes a
real header.
https://bugzilla.gnome.org/show_bug.cgi?id=733487
Otherwise those checks may fail at configure time if they contain extra
include paths, while at build time they are included, potentially causing
incompatible typedefs between system GL headers and gstreamer compatibility
prototypes.
https://bugzilla.gnome.org/show_bug.cgi?id=733248
They should be handled in tandem, in case any EGL provider could require some
CFLAGS and set them (possibly once moved to prefer pkg-config files),
such as for a custom header location.
Clang will only give a warning for the redefinition of typedef GLenum.
Since master is build with -Werror this will result in a build failure
later in the gl plugin. Add -Werror to the test, so the test result is as
expected. This will allow the gl plugins to build.
https://bugzilla.gnome.org//show_bug.cgi?id=731692
