GNOME Bugzilla – Bug 757577
gstreamer-vaapi 0.6.1 fails to build on 32bit
Last modified: 2015-11-09 14:47:58 UTC
Created attachment 314803 [details] failing compile log We were trying to upgrade gstreamer-vaapi in Yocto from 0.5.10 to 0.6.1 but are facing compile problems on 32bit platforms. Below is an example: | In file included from /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/gstreamer-1.0/gst/gl/gstglapi.h:61:0, | from /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/gstreamer-1.0/gst/gl/gstgl_fwd.h:26, | from /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/gstreamer-1.0/gst/gl/gl.h:29, | from /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/gstreamer-1.0/gst/gl/gstglcontext.h:26, | from /home/jku/src/poky/build/tmp/work/i586-poky-linux/gstreamer-vaapi-1.0/0.6.1-r0/gstreamer-vaapi-0.6.1/gst/vaapi/gstvaapipluginbase.h:36, | from /home/jku/src/poky/build/tmp/work/i586-poky-linux/gstreamer-vaapi-1.0/0.6.1-r0/gstreamer-vaapi-0.6.1/gst/vaapi/gstvaapipluginutil.c:43: | /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/GLES2/gl2.h:69:25: error: conflicting types for 'GLsizeiptr' | typedef khronos_ssize_t GLsizeiptr; | ^ | In file included from /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/GL/gl.h:2055:0, | from /home/jku/src/poky/build/tmp/work/i586-poky-linux/gstreamer-vaapi-1.0/0.6.1-r0/gstreamer-vaapi-0.6.1/gst-libs/gst/vaapi/gstvaapidisplay_glx.h:28, | from /home/jku/src/poky/build/tmp/work/i586-poky-linux/gstreamer-vaapi-1.0/0.6.1-r0/gstreamer-vaapi-0.6.1/gst/vaapi/gstvaapipluginutil.c:34: | /home/jku/src/poky/build/tmp/sysroots/qemux86/usr/include/GL/glext.h:468:19: note: previous declaration of 'GLsizeiptr' was here | typedef ptrdiff_t GLsizeiptr; | ^ gst-plugins-bad was compiled with gles2 support and that seems to result in it including GLES2 headers (/usr/include/GLES2/gl2.h) in it's public headers. These clash with GL headers (/usr/include/GL/gl.h) that gstreamer-vaapi includes. I'm not familiar enough with GL to figure out where the problem is but Sreerenj suggested I file a bug here.
Created attachment 314807 [details] configure log This is the corresponding configure log. This particular test was done with --disable-egl but the failure also appears with egl.
@Jussi: Thanks for reporting: Similar one is here: https://bugzilla.gnome.org/show_bug.cgi?id=753099 @Victor: IIUC you are currently fixing the gl related issues ... Could you please have a look into this one too?
(In reply to sreerenj from comment #2) > @Jussi: Thanks for reporting: > Similar one is here: https://bugzilla.gnome.org/show_bug.cgi?id=753099 > > @Victor: IIUC you are currently fixing the gl related issues ... > Could you please have a look into this one too? It's a bit different. AFAIK we should prevent the inclusion of glext.h and glxext.h if they are already included by other dependency, in this case GstGL: https://www.opengl.org/registry/ABI/ One workaround could be to disable glx and enable egl, since gles2 is used, though gles2 can use glx too.
(In reply to Víctor Manuel Jáquez Leal from comment #3) > (In reply to sreerenj from comment #2) > > @Jussi: Thanks for reporting: > > Similar one is here: https://bugzilla.gnome.org/show_bug.cgi?id=753099 > > > > @Victor: IIUC you are currently fixing the gl related issues ... > > Could you please have a look into this one too? > > It's a bit different. AFAIK we should prevent the inclusion of glext.h and > glxext.h if they are already included by other dependency, in this case > GstGL: Could you please provide a patch for conditional compilation so that Jussi can test...? > > https://www.opengl.org/registry/ABI/ > > One workaround could be to disable glx and enable egl, since gles2 is used, > though gles2 can use glx too.
It should be reproducible in 64 bit too,,,is it not the case Jussi?
The compile (In reply to sreerenj from comment #5) > It should be reproducible in 64 bit too,,,is it not the case Jussi? compiling for qemu86-64 worked fine: I still get the same warnings you see in the attached compile log (where things like GL_RGB16 are redefined) but the pointer sizes seem to be same so there are no conflicting type errors.
@Victor: Does gst-plugins-bad has separate guarding for GL and GLES2 definitions(eg: diff types for GLsizeiptr)? Since we have the option for run-time selection of GL/GLES2 with GST_GL_API environment variable, wondering how it worked in gst-plugins-bad...
Created attachment 314836 [details] [review] libs: remove unneeded headers Since gstvaapidisplay_glx.h do not expose gl.h/glx.h structures, it is not required to include them in the header. It is not also required to include them in gstvaapidisplay_glx.c, since gstvaapiutils_glx.h includes them and exposes their structures (e.g. GLXPixmap). Nonetheless, glext.h neither glxext.h are required to include, they are already included conditionally by gl.h and glx.h, respectively. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
@jussi let me know if with that patch works for you. In my 64bit setup the warnings don't show up anymore.
I'm out of my depth to evaluate if it's the correct patch -- but I can say it does fix the build failure on 32 bits. Thanks for quick response, both Victor and Sreerenj.
(In reply to Jussi Kukkonen from comment #10) > I'm out of my depth to evaluate if it's the correct patch -- but I can say > it does fix the build failure on 32 bits. Thanks for quick response, both > Victor and Sreerenj. Cool. IMO the patch is correct, what do you think @sree?
(In reply to Víctor Manuel Jáquez Leal from comment #11) > (In reply to Jussi Kukkonen from comment #10) > > I'm out of my depth to evaluate if it's the correct patch -- but I can say > > it does fix the build failure on 32 bits. Thanks for quick response, both > > Victor and Sreerenj. > > Cool. > > IMO the patch is correct, what do you think @sree? What if GLX_GLXEXT_LEGACY or GL_GLEXT_LEGACY were set by the user while compiling mesa? As per what I can see in gl header, the inclusion of extensions are based on these environmental variables...right?
(In reply to sreerenj from comment #12) > What if GLX_GLXEXT_LEGACY or GL_GLEXT_LEGACY were set by the user while > compiling mesa? Those preprocessor directives are for applications, not for mesa. Actually, internally mesa doesn't do anything with them, just gl.h loads or not glxext.h/glext.h in compilation-time > As per what I can see in gl header, the inclusion of extensions are based on > these environmental variables...right? Though mesa manages several environment variables, none of them handle the GL extension. But I'm not sure. What I know is that GstGL indeed uses environment variables to choose the GL api and platform to use in run-time. In gstreamer-vaapi we were loading, in compilation-time, the definition of structures that collided with previous loaded definitions. The patch fences the loading to the parts of the code that truly require it: the GLX.
(In reply to Víctor Manuel Jáquez Leal from comment #13) > (In reply to sreerenj from comment #12) > > > What if GLX_GLXEXT_LEGACY or GL_GLEXT_LEGACY were set by the user while > > compiling mesa? > > Those preprocessor directives are for applications, not for mesa. Actually, > internally mesa doesn't do anything with them, just gl.h loads or not > glxext.h/glext.h in compilation-time > > > As per what I can see in gl header, the inclusion of extensions are based on > > these environmental variables...right? > > Though mesa manages several environment variables, none of them handle the > GL extension. But I'm not sure. > > What I know is that GstGL indeed uses environment variables to choose the GL > api and platform to use in run-time. > > In gstreamer-vaapi we were loading, in compilation-time, the definition of > structures that collided with previous loaded definitions. The patch fences > the loading to the parts of the code that truly require it: the GLX. Suppose if we have GL and GLES2 headers installed and gstreamer-vaapi compiled with --with-glapi as default "any" option, then the run time selection of gl-apis should work too,,,is it not the case at the moment? BTW, how the upstream plugins-bad handling both GL and GLES2 if both installed system wide. Do they have any condition checking for "GL/gl.h" and "GLES2/gl2.h" ? Since they support run time selection, they should include both definitions , for eg: "typedef khronos_ssize_t GLsizeiptr" and "typedef ptrdiff_t GLsizeiptr".. Or am I saying something nonsense ?? :) Anyway I am okay with your patch...please push...
(In reply to sreerenj from comment #14) > Suppose if we have GL and GLES2 headers installed and gstreamer-vaapi > compiled with --with-glapi as default "any" option, then the run time > selection of gl-apis should work too,,,is it not the case at the moment? It should. When GstGLContext is negotiated by vaapidecode, for example, the instance of GstGLContext specifies the display type (gst_vaapi_plugin_base_set_gl_context() and gst_vaapi_create_display_from_gl_context()). > BTW, how the upstream plugins-bad handling both GL and GLES2 if both > installed system wide. Do they have any condition checking for "GL/gl.h" and > "GLES2/gl2.h" ? Since they support run time selection, they should include > both definitions , for eg: "typedef khronos_ssize_t GLsizeiptr" and "typedef > ptrdiff_t GLsizeiptr".. GstGL (gstglapi.h) first loads GLES2 and then GL. But it defines GL_GLEXT_PROTOTYPES[1], then the structure definitions in GL are used. However, in this particular case, GL doesn't exist in the system, so this definition is ignored and GLES2 structure definitions were loaded, triggering this bug report. 1. http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglapi.h#n29 > Anyway I am okay with your patch...please push... Pushing right now.
Attachment 314836 [details] pushed as f182fcf - libs: remove unneeded headers