GNOME Bugzilla – Bug 726666
gl: error: redundant redeclaration of numerous GL functions
Last modified: 2014-05-09 07:33:15 UTC
Created attachment 272320 [details] make error output gst-plugins-bad fails to compile at the gst/gl/x11 level due to redundant redeclarations of GL api's enforced by the -Werror=redundant-decls flag. See attached make error log for more details. S/W Stack ---------- wayland (master) heads/master-0-g3adcf6f drm (master) heads/master-0-g230389a mesa (master) heads/master-0-gf74cf5f libva (master) heads/master-0-gffdcb50 intel-driver (master) heads/master-0-gf393de5 gstreamer (master) heads/master-0-g888cf06 gst-plugins-base (master) heads/master-0-gb7cf2fa gst-plugins-good (master) heads/master-0-g759ea92 gst-plugins-bad (master) heads/master-0-g7b15072 gst-ffmpeg (master) heads/master-0-g0326da1 gstreamer-vaapi (master) heads/master-0-ge52d394
Created attachment 272321 [details] configure log
Last known good commit is dbb42d914f3
(In reply to comment #2) > Last known good commit is dbb42d914f3 ok so the problem may be already there in gst-plugins-gl . Could you please try to bisect starting from [875/906] ?
6b3fe4418538bcdb8ccccd274ba22764ae203e6f is the first bad commit commit 6b3fe4418538bcdb8ccccd274ba22764ae203e6f Author: Matthew Waters <ystreet00@gmail.com> Date: Sun Mar 16 15:08:23 2014 +0100 Move gst-plugins-gl to bad :100644 100644 ac063c9cbd0a024ecf990ffce4f002ee046968e0 c9d76cb17748bcc76001bb2d0a514c007ded7e2a M configure.ac :040000 040000 10893d99b403415fdd16ff7b07ac9deccbcaf9b9 0af02ba900816b45cf19a4341ca1195176f3a04d M docs :040000 040000 51480a6d694597a9096678ac87af3034c169cb2c ce4e300cea83463fc9641da3cf1ef434a0be341e M ext :040000 040000 6ba045331a0f61ed7a7a8f3530a2a71a88d7bb54 abca03ce28ab691e4134a5f453165769e6e884c1 M gst-libs :040000 040000 2e3dcb86b038c11373a20c30f3c9ddc9683059ff 5a524865b88875c59278330309797bb1303b550c M tests bisect run success
Could you please try to do the same analyse but in gst-plugins-gl directly ?
(In reply to comment #5) > Could you please try to do the same analyse but in gst-plugins-gl directly ? Not sure what you mean... could you be a bit more specific?
(In reply to comment #6) > (In reply to comment #5) > > Could you please try to do the same analyse but in gst-plugins-gl directly ? > > Not sure what you mean... could you be a bit more specific? You mean with the recent patches that were pushed?
Well I was guessing git bisect could be confused due to the move of lot commits in a row but it should not. Also maybe faster to reach the "cause" commit running git bisect in gst-plugins-gl to make sure to fall on a "gl" commit every step. What were your exact steps with git bisect ?
At the top level with HEAD=759ea92, I ran: $ git bisect start HEAD cba72fbee33847dca $ git bisect run ./buildit.sh Where ./buildit.sh is: ------ #!/bin/sh make distclean set -e ./autogen.sh --prefix=$PREFIX --disable-gtk-doc --enable-wayland --disable-examples make -j 6 make -j 6 install ------ Then for sanity I ran the following: $ git bisect reset $ git reset --hard 6b3fe4418538bcdb8ccccd274ba22764ae203e6f $ ./buildit.sh # build fail $ git reset --hard HEAD~1 $ ./buildit.sh # build success
Build will not work for all commits like [x/906]. I think bisect assumes that because they are part of a move. So I guess bisect does not try them at all. That's why I think bisect actually starts from 6b3fe4418538bcdb8ccccd274ba22764ae203e6f instead of cba72fbee33847dca3425cd93ce0bd7a10660990 So you have to checkout gst-plugins-gl and run bisect in there :)
(In reply to comment #10) > Build will not work for all commits like [x/906]. ...hmmm, I did a sanity check by *manually* compiling the commit flagged as FBC (6b3fe44185) and the commit right before that. That is, the commit *right before* 6b3fe44185 manually compiles fine, but 6b3fe44185 does not. Nonetheless, I'll try your suggestions ;) FWIW, I just discovered that I'm not having any issues compiling it on my other development machine. On that machine, I'm compiling the same s/w stack (^above^) without issue in a systemd-nspawn container with minimally installed system devel packages. Perhaps the system I'm having issues compiling on has some conflicting packages installed that are causing cross-contamination issues. I'm investigating this some more. I suspect it might have something to do with my custom mesa [GL/EGL/GLES] install vs. the system installed ones that gst-plugins-gl is having trouble with. In general, however, I haven't had this type of problem with other gl/egl/gles-based s/w projects :-/
Ok, so I build and install my s/w stack (including mesa [GL/GLES/EGL]) into a non-standard, custom prefix... but I also have mesa devel packages installed on my system. When I'm building my s/w stack I export the following environment variables: PREFIX = ~/my/custom/install/ LD_LIBRARY_PATH = $PREFIX/lib/ ACLOCAL = aclocal -I $PREFIX/share/aclocal/ PKG_CONFIG_PATH = $PREFIX/share/pkgconfig/ CPPFLAGS = -I$PREFIX/include LDFLAGS = -L$PREFIX/lib PKG_CONFIG_PATH = $PREFIX/lib/pkgconfig/:$PREFIX/share/pkgconfig/ If I uninstall my system installed mesa devel packages, then gst-plugins-gl finds my custom installed mesa GL/GLES/EGL and compiles fine. So it seems gst-plugins-gl isn't honoring/prioritizing my custom installed mesa if there are system mesa devel packages installed, too.
Doh, of course... silly me. I realize that prior to the FBC I'm having issues with doesn't actually try to build gst-plugin-gl which is why I've never encountered this issue. As a corollary, I suspect bisecting gst-plugins-gl *directly* won't get me anywhere based on my last comment. Nonetheless, I apparently never needed/used it anyway. So I'll just *--disable-opengl* for now.
As(In reply to comment #0) > Created an attachment (id=272320) [details] > make error output > It was in front of my eyes and I just saw the problem :) /home/uartie/Work/wayland/install/include/GL/gl.h:754:23: error: redundant redeclaration of 'glClearColor' /home/uartie/Work/wayland/install/include/GLES2/gl2.h:393:29: note: previous declaration of 'glClearColor' was here So it both includes GL/gl.h and GLES2/gl2.h. Also in the configure log we can see it founded both glx/gl and egl/gles2. We have flags to select the platform and the windowing system, but not for the gl api, at runtime I mean. GST_GL_PLATFORM=glx GST_GL_WINDOW=x11 gst-launch-1.0 videotestsrc ! glimagesink GST_GL_PLATFORM=egl GST_GL_WINDOW=x11 gst-launch-1.0 videotestsrc ! glimagesink As you can see in line 50 and 64 of http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglapi.h, currently if both gl and gles2 are present then it includes both headers and it results in the error you got. Ullysses for now you can try either passing either "--disable-glx --disable-opengl" or "--disable-egl --disable-gles2" If you know that you want that on wayland only then also add --disable-x11. Matthew I wonder if this could be possible to select opengl or gles2 at runtime through a env var too ? Then if at runtime it will actually be able to run only one then that would be still ok so that there is no build error. If yes then we should rename this bug to "add support to select gl API at runtime"
You already can select at runtime using GST_GL_API=gles2,opengl,etc See http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglcontext.c#n711 It seems we should try and detect the case where we cannot include both GLES2 and GL headers. The only way I can see is to try a test compile with the includes and see what fails.
commit dca6e5e039f5acea6a1e33718b81b32ee46a6b4a Author: Matthew Waters <ystreet00@gmail.com> Date: Mon May 5 20:06:29 2014 +1000 gl: check if we can include both GL and GLES2 headers at the same time If we cannot, then default to GL over GLES2 unless GLES2 is required.