GNOME Bugzilla – Bug 770987
configure.ac EGL checks clobber user EGL_LIBS/EGL_CFLAGS
Last modified: 2018-11-03 11:49:42 UTC
If configure.ac finds EGL it sets EGL_CFLAGS to empty, and sets EGL_LIBS to a fixed string: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/configure.ac#n789 Then later it sets GL_CLFAGS and GL_LIBS to empty: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/configure.ac#n826 And then finally it does this: GL_LIBS="$GL_LIBS -lEGL $EGL_LIBS" GL_CFLAGS="$GL_CFLAGS $EGL_CFLAGS" At this point all the variables are empty. The result of this is that if you need to specify EGL_CFLAGS/EGL_LIBS to make EGL work, then your options will not be passed through to the actual compile. This is for example the reason why you need to put loads of stuff into LDFLAGS, CFLAGS, CPPFLAGS when building on the raspberry pi as in this bug: https://bugzilla.gnome.org/show_bug.cgi?id=740530 Note that the Mali EGL detection branch does the same thing.
Also note that the workaround of stuffing everything into the global CFLAGS/CPPFLAGS/LDFLAGS/LIBS only works for the main build. It does not work for building G-I because g-ir-scanner ignores everything except -D in those variables.
And see also https://bugzilla.gnome.org/show_bug.cgi?id=770988 because even if you do manage to get these variables set correctly, GL_LIBS won't actually be used when building G-I, so it will fail anyway.
Do you want to provide a patch for this? Looks indeed all a bit messy and wrong :)
Some history: Originally, EGL/GLES2/GL_CFLAGS/LIBS weren't exposed as overridable. They came about because of bug 751068 when adding the pkg-config support. For this, it probably makes sense to move all the resulting flags into GST_GL_{CFLAGS,LIBS,WHATEVER} and don't tread on pkg-config's toes here. Then (or before), you can allow overriding the various GL/GLES2/EGL_CFLAGS/LIBS, etc.
I don't think this is fixable, or if it is then it is beyond my ability. The problem is basically that when the RPi check runs, EGL_CFLAGS/LIBS can contain one of three different things: 1. Flags from pkg-config. 2. Flags from the user. 3. Nothing at all. Additionally the values can: A. Work. B. Work, but point to the wrong EGL implementation. C. Not work at all. So what the check does is completely ignore EGL_CFLAGS/LIBS and test directly for the Broadcom libs. If it finds them then it throws away any existing value and rewrites the variables from scratch. Thus preventing pkg-config from picking the wrong implementation. But where this fails is when you have the libs outside the system path. Then you have to use the global LIBS and CPPFLAGS (because LDFLAGS and CFLAGS won't actually work) - because the check ignores EGL_* and then if it successeds it overwrites them with incomplete hard coded information. I could fix it so it doesn't ignore user supplied values, but then it will probably break for someone else. I did implement GST_GL_* but it doesn't actually change anything for me. I also found a couple of other bugs while doing that.
(In reply to Alistair Buxton from comment #5) > I don't think this is fixable, or if it is then it is beyond my ability. > > The problem is basically that when the RPi check runs, EGL_CFLAGS/LIBS can > contain one of three different things: > > 1. Flags from pkg-config. > 2. Flags from the user. > 3. Nothing at all. IIRC, pkg-config will not overwrite the EGL flags (or any other flags) if they are set already. We just need to do the same. > Additionally the values can: > > A. Work. > B. Work, but point to the wrong EGL implementation. > C. Not work at all. > > So what the check does is completely ignore EGL_CFLAGS/LIBS and test > directly for the Broadcom libs. If it finds them then it throws away any > existing value and rewrites the variables from scratch. Thus preventing > pkg-config from picking the wrong implementation. This problem can be "fixed" I think by moving the pkg-config detection after the rpi/mali specific detection as pkg-config won't override user set variables. > But where this fails is when you have the libs outside the system path. Then > you have to use the global LIBS and CPPFLAGS (because LDFLAGS and CFLAGS > won't actually work) - because the check ignores EGL_* and then if it > successeds it overwrites them with incomplete hard coded information. > > I could fix it so it doesn't ignore user supplied values, but then it will > probably break for someone else. This is the correct fix and should be completed. > I did implement GST_GL_* but it doesn't actually change anything for me. This is mostly for the GL side so we don't override pkg-config/user's choice for the opengl library (not gles2). > I also found a couple of other bugs while doing that. Patches! patches! everywhere.
As of Raspbian stretch there is an additional complication: the EGL and GLESv2 .so have been renamed to libbrcmEGL.so and libbrcmGLESv2.so in order to avoid conflicts with mesa. In jessie both so names are available, but in stretch the old names have been removed. So now anything that wants to use broadcom EGL must link against the libbrcm*.so. This might be easier to deal with - that's the idea anyway. But at the moment I can't get gst-plugins-bad to accept this at all. It keeps trying to compile a test with -lGLESv2 which fails.
Created attachment 356615 [details] [review] Patch to configure.ac I managed to get it to build against the new .so names. I did it by setting NEED_EGL and NEED_GLES2 to no in order to prevent the later checks from clobbering the GL_LIBS, then setting USE_EGL and USE_GLES2 to yes and manually setting GL_LIBS to the right thing. This is pretty ugly but I don't have enough skills in autotools to fix it properly. This is basically the same problem as before: the later checks mess up the GL_LIBS no matter what sets them, only now "-lEGL -lGLESv2" won't work at all because those so names don't exist at all.
Created attachment 356618 [details] [review] Patch to configure.ac Previous patch didn't work at all because those vars get reset. This one takes a different approach. It uses the second to last clause in the GL setup, which is a dispmanx section, to setup the vars, and then skips the last clause when dispmanx is in use, so the GL_LIBS does not get changed again. This one I have tested actually works, but it's still not a full solution.
Does stretch finally have pkg-config files for EGL and GLESv2 for broadcom, if so, you should definitely be using them instead of passing libraries manually. The meson build deals with this however I'm not sure how well the autotools deals with that.
Unfortunately it does not - apparently Yocto does, but they move everything around anyway.
raspbian seem to: pi@raspberrypi:~ $ dpkg -L libraspberrypi-dev | grep pkgconfig /opt/vc/lib/pkgconfig/bcm_host.pc /opt/vc/lib/pkgconfig/brcmegl.pc /opt/vc/lib/pkgconfig/brcmglesv2.pc /opt/vc/lib/pkgconfig/brcmvg.pc /opt/vc/lib/pkgconfig/mmal.pc /opt/vc/lib/pkgconfig/vcsm.pc pi@raspberrypi:~ $ PKG_CONFIG_PATH=/opt/vc/lib/pkgconfig pkg-config --cflags --libs brcmglesv2 -DUSE_VCHIQ_ARM -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -L/opt/vc/lib -lbrcmGLESv2 -lbcm_host -lvcos -lvchiq_arm -pthread
That's new. Added to the package after my previous comment. This still won't let gstreamer build without patching the autotools scripts though, because the supplied configs all have brcm prefixes, and so the existing scripts won't be able to detect them (and can't be overridden in any way, which is the original topic of this bug.)
Doing some work on this today. If I symlink brcmegl.pc to egl.pc then gstreamer will find and use it. However, it still refuses the build the gl plugins because the autotools tests are hardcoded to use libEGL.so instead of the libs that pkg-config tells it to use.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/290.