Until recently, media-libs/mesa notably EGL did skip over the inclusion of X11 headers only if MESA_EGL_NO_X11_HEADERS was defined prior to inclusion of <eglplatform.h>. This was useful for pure Wayland systems which supported EGL without Xlib etc. Looking at /usr/include/EGL/eglplatform.h this seems to have changed. The inclusion of X11 headers is now conditioned by a definition of EGL_NO_X11 (c.f. line 119ff). Consequently, packages which use Mesa now fail to build. I've encountered this with media-video/mpv, x11-libs/gtk+, net-libs/webkit-gtk, but I suspect only very few packages if any were updated to match this change at Mesa.
Created attachment 632728 [details] 100 lines tail of building gtk+-3.24.16
Created attachment 632730 [details] emerge info
Are you using libglvnd? The only difference between Mesa's eglplatform.h and libglvnd's is --- /usr/include/EGL/eglplatform.h 2020-02-21 13:28:47.000000000 -0800 +++ include/EGL/eglplatform.h 2020-01-28 14:45:42.617299213 -0800 @@ -55,6 +55,12 @@ #endif #define EGLAPIENTRYP EGLAPIENTRY* +#if defined(MESA_EGL_NO_X11_HEADERS) && !defined(EGL_NO_X11) +#warning "`MESA_EGL_NO_X11_HEADERS` is deprecated, and doesn't work with the unmodified Khronos header" +#warning "Please use `EGL_NO_X11` instead, as `MESA_EGL_NO_X11_HEADERS` will be removed soon" +#define EGL_NO_X11 +#endif + /* The types NativeDisplayType, NativeWindowType, and NativePixmapType * are aliases of window-system-dependent types, such as X Display * or * Windows Device Context. They must be defined in platform-specific The file still contains #elif defined(__unix__) && defined(EGL_NO_X11) typedef void *EGLNativeDisplayType; typedef khronos_uintptr_t EGLNativePixmapType; typedef khronos_uintptr_t EGLNativeWindowType; #elif defined(__unix__) || defined(USE_X11) /* X11 (tentative) */ #include <X11/Xlib.h> #include <X11/Xutil.h> ... so you should define EGL_NO_X11. Presumably something was defining MESA_EGL_NO_X11_HEADERS and Mesa's deprecation warning was not heeded, so now with libglvnd it's broken.
I don't know what defines/defined MESA_EGL_NO_X11_HEADERS. I don't see it defined in gtk or mpv (nor do I see EGL_NO_X11).
My mistake, the file is part of libglvnd, indeed. Then I can't say. As far as I recall, libglvnd replaced that part of mesa only recently and this might have caused it? I honestly can't tell why it worked before or who defined MESA_EGL_NO_X11_HEADERS. Whatever it was though it doesn't seem to work now.
Carefully, I might add that I did some related local modifications to libepoxy long ago. I had thought that I reverted that to upstream libepoxy shortly after, but I might be mistaken and this bug re-appeared for me because libepoxy was rebuilt.
Did you figure this out? I haven't see any other reports, so I'm suspecting that it's something you did to your local system.
I (re-?)introduced EGL_NO_X11 into my epoxy header which allowed me to compile Gtk. I think the absence of other people having this problem is quite simply because it's rather rare not to have X11 headers installed.
IIRC, I was told that there were according patches for epoxy proposed upstream long ago but were rejected. Since epoxy has an X USE flag I thought this had eventually gone through or been patched by Gentoo...? As it is, I suppose there are two "proper" solutions now: a) Patch epoxy so that this actually becomes the case or b) DEPEND on libX11 by epoxy. (I'd obviously prefer a).
(In reply to Cedric Sodhi from comment #8) > I (re-?)introduced EGL_NO_X11 into my epoxy header which allowed me to > compile Gtk. I think the absence of other people having this problem is > quite simply because it's rather rare not to have X11 headers installed. I agree it's rare, but I get a lot of bug reports about a lot of weird configurations. If this is a bug, then I'm surprised to not have received other reports.
Having still seen no other instances of this, I'm going to speculatively close this bug as invalid. The mention of local patches suggests to me that that it's likely to be a local problem.
I do not concur with that assessment. > The mention of local patches suggests to me that that it's likely to be a local problem. This sounds illogical to me. There are no local patches when the error occurs; a local patch only helped me. I don't see how this kind of mention would suggest that the problem be local. I do not have any (other) patches or overlays applied in even remotely relevant areas. I know for a fact that my setup is very rare and, indeed, I have never encountered anyone - even among those who use "pure" Wayland - who doesn't even X headers installed. For a long time mesa would not even compile like that. I would concur if there had been someone to say that they have a setup without libX headers and that they worked for them. But not even that is the case, I therefore can't comprehend why you decide to close this.
Ah, I think I misunderstood when you said > Carefully, I might add that I did some related local modifications to libepoxy long ago. I had thought that I reverted that to upstream libepoxy shortly after, but I might be mistaken and this bug re-appeared for me because libepoxy was rebuilt. Thank you for being calm and polite. It's a pleasant surprise when a user doesn't want to rip my head off in a situation like this. :) Reopening.
Sorry for the late reply. According to what I've been told, the correct way to solve this is that libglvnd does export the correct Cflags in the according .pc file (or according makesystem file). Could this bug be correctly assigned please?
(In reply to Cedric Sodhi from comment #14) > Sorry for the late reply. According to what I've been told, the correct way > to solve this is that libglvnd does export the correct Cflags in the > according .pc file (or according makesystem file). Could this bug be > correctly assigned please? It is correctly assigned. x11@ maintains mesa, libepoxy, libglvnd...
Could be fixed by the libepoxy-1.5.5 bump per bug 718794.
*** Bug 759448 has been marked as a duplicate of this bug. ***
(In reply to Matt Turner from comment #16) > Could be fixed by the libepoxy-1.5.5 bump per bug 718794. Using libepoxy-1.5.5 with -X does not fix building media-video/mpv, x11-libs/gtk+, net-libs/webkit-gtk without libX11.
Created attachment 700575 [details] /var/tmp/portage/x11-libs/gtk+-3.24.26/temp/build.log I have encountered the same problem trying to build x11-libs/gtk+-3.24.26 in a wayland -X environment: [ebuild N ] x11-libs/gtk+-3.24.26 USE="wayland -X (-aqua) -broadway -cloudprint -colord -cups -examples -gtk-doc -introspection -sysprof -test -vim-syntax -xinerama"
Yeah, epoxy-1.5.5 didn't do anything for me either. I put > #define EGL_NO_X11 back into my /usr/include/epoxy/egl.h for the time being.
I hacked <EGL/eglplatform.h> to fix the gtk build. It might even work for other packages too. --- /usr/include/EGL/eglplatform.h 2020-06-25 23:17:25.000000000 +0100 +++ /mnt/usr/include/EGL/eglplatform.h 2021-04-18 16:35:44.121957500 +0100 @@ -116,7 +116,7 @@ typedef intptr_t EGLNativePixmapType; typedef intptr_t EGLNativeWindowType; -#elif defined(__unix__) && defined(EGL_NO_X11) +#elif defined(__unix__) && ! defined(USE_X11) typedef void *EGLNativeDisplayType; typedef khronos_uintptr_t EGLNativePixmapType;
Ran into this one myself while installing on _stable_ amd64, without X. It's an installation from scratch, after many years away from any Linux.
Matt, I figure this should be closed by https://github.com/KhronosGroup/EGL-Registry/pull/130 but not sure whether UPSTREAM or FIXED, if you would do the honors, please!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d05580c3f1ba502d81cd3513daf494680061526 commit 9d05580c3f1ba502d81cd3513daf494680061526 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-08-24 19:57:41 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-08-24 20:01:28 +0000 media-libs/libglvnd: Version bump to 1.3.4 Closes: https://bugs.gentoo.org/717352 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/libglvnd/Manifest | 1 + media-libs/libglvnd/libglvnd-1.3.4.ebuild | 65 +++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+)
