GNOME Bugzilla – Bug 751068
gl: Use pkg-config if found to configure GL/EGL/GLES (as provided by mesa and libmali)
Last modified: 2015-12-16 00:30:29 UTC
Created attachment 305418 [details] config.log from a failed configure run configure fails both the usability and presence tests for EGL/egl.h configure appears to be building a simple test program that includes EGL/egl.h but doesn't follow the cflags in egl.pc which indicate that -DMESA_EGL_NO_X11_HEADERS should be used This results in an attempt to include missing X11 headers, hilarity ensues.
That's sad, now we have to check for EGL with pkg-config and by header/library. Want to provide a patch? :) Probably have to do the same for GL, GLESv2, GLX, too
Annoyingly, mesa is the only pkg-config provider for any GL related libraries. There are of course work arounds like CFLAGS, LDFLAGS so this is not a massive deal. Interesting that mesa chose to go with a define rather than generating a config header.
*** Bug 758011 has been marked as a duplicate of this bug. ***
It's weird to see that we argue against what we usually teach people to be the right thing. Anyway, that shall be fixed, the libmali is following this recommendation now. Can't blame OSX/iOS and Windows stuff though, as pkg-config is not tradition there.
I'm not arguing against the usefulness of pkg-config files, they are definitely useful. Just that for GL this seems a rather annoying change for two reasons: 1) people were using their own checks based on headers/libs since decades and on other platforms we still need them 2) non-pkg-config checks are going to fail now because a special #define is needed that is given in the pkg-config file only I would say that 2) is something that mesa should really fix unless they want to make many people unhappy because suddenly their software fails to build. Nonetheless it would make sense from our side to use pkg-config if available, and fall back to other checks otherwise. If someone wants to provide a patch.
I don't think the CFLAGS/LIBS argument is valid, because on those grounds why would we bother ever transitioning any package to pkg-config? Yes, you will have to retain the old header/lib checks, but it means that people installing Mesa (or newer versions of some other implementations) can have things just work as expected. It also matches the behaviour of Weston, Cogl, and others. As far as the header 'fix' goes, unfortunately that's not ever going to happen for various unpleasant reasons. Firstly, let's be clear that it _only_ occurs on systems without X11 headers installed. Secondly, the core EGL headers come from Khronos, and part of their behaviour/API is that on Unix-based platforms, they include Xlib.h, so they can define EGLNativeDisplayType as Display *, EGLNativeWindowType as Window, etc. Obviously this is a bad idea - the forest of #ifdef in eglplatform.h tells you as much. EGL_EXT_platform_base resolves that madness, but we'll continue to have this issue for as long as the classic EGL API is supported, i.e. forever. At one point we did look at generating eglplatform.h to automagically work around the #include issue, but we concluded that would just break other naïve apps, as well as introduce a build failure mode which only existed on Mesa and nowhere else. So the best solution from a very very bad bunch was to introduce a #define which would allow you to build without X11 headers, and to put that in the pkg-config file so that apps who didn't particularly care would get the best possible chance of working if they just used pkg-config. Alternative suggestions are welcome, but I'm really having trouble seeing the downside.
Created attachment 317397 [details] [review] opengl: Use pkg-config if available libMesa ships .pc files now for gl/egl/glesv2. This patch makes use of it while keeping support for system without.
Attachment 317397 [details] pushed as 8265aca - opengl: Use pkg-config if available
Thanks for reporting.
I found some more difficulties (specially for builds with -Wall -Werror enabled). I also found a case where we'd be using the wrong headers. Those two patches hopefully fixes it. commit 516047f66f3acc5dd3b975c5d0abcee0d98c9316 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Dec 15 19:28:05 2015 -0500 qtsink: Add configured GL cflags to the build We don't directly link to GL in the element, though we use GL headers. For this reason we need to include the proper GL headers path. This prevent this element from using a different GL header then libgstgl. commit 4c19b415bd75accbb13cb4a4149e6858f6f37f9c Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Dec 15 19:25:16 2015 -0500 gl: Allow using non-system mesa with both GL and GLES GCC automatically disable redundance warnings for system headers. As soon as we start using a non-system installed mesa, we would start having issues. The test for both wasn't setting any flags, so it would work but then fail at runtime. This is being fixed by disabling in the code (where needed only) that GCC warning. The test is also fixed to avoid the false positive we had.