Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 717352 - media-libs/libglvnd-1.3.1 Packages which build against libglvnd's (E)GL headers fail without X11 headers
Summary: media-libs/libglvnd-1.3.1 Packages which build against libglvnd's (E)GL heade...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: PATCH
Depends on: 767265
Blocks:
  Show dependency tree
 
Reported: 2020-04-13 18:15 UTC by Cedric Sodhi
Modified: 2021-04-23 16:34 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
100 lines tail of building gtk+-3.24.16 (build.log,29.43 KB, text/plain)
2020-04-13 18:19 UTC, Cedric Sodhi
Details
emerge info (info.txt,5.39 KB, text/plain)
2020-04-13 18:19 UTC, Cedric Sodhi
Details
/var/tmp/portage/x11-libs/gtk+-3.24.26/temp/build.log (build.log,48.76 KB, text/plain)
2021-04-18 15:29 UTC, junkmailnotread
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric Sodhi 2020-04-13 18:15:37 UTC
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.
Comment 1 Cedric Sodhi 2020-04-13 18:19:16 UTC
Created attachment 632728 [details]
100 lines tail of building gtk+-3.24.16
Comment 2 Cedric Sodhi 2020-04-13 18:19:59 UTC
Created attachment 632730 [details]
emerge info
Comment 3 Matt Turner gentoo-dev 2020-04-13 20:21:36 UTC
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.
Comment 4 Matt Turner gentoo-dev 2020-04-13 20:26:30 UTC
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).
Comment 5 Cedric Sodhi 2020-04-14 06:46:15 UTC
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.
Comment 6 Cedric Sodhi 2020-04-14 06:49:56 UTC
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.
Comment 7 Matt Turner gentoo-dev 2020-04-20 00:03:27 UTC
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.
Comment 8 Cedric Sodhi 2020-04-20 07:48:22 UTC
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.
Comment 9 Cedric Sodhi 2020-04-20 07:52:14 UTC
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).
Comment 10 Matt Turner gentoo-dev 2020-04-21 18:43:37 UTC
(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.
Comment 11 Matt Turner gentoo-dev 2020-04-30 17:23:17 UTC
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.
Comment 12 Cedric Sodhi 2020-04-30 19:07:04 UTC
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.
Comment 13 Matt Turner gentoo-dev 2020-04-30 21:04:26 UTC
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.
Comment 14 Cedric Sodhi 2020-06-21 07:27:45 UTC
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?
Comment 15 Matt Turner gentoo-dev 2020-06-22 18:19:20 UTC
(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...
Comment 16 Matt Turner gentoo-dev 2020-12-24 04:36:37 UTC
Could be fixed by the libepoxy-1.5.5 bump per bug 718794.
Comment 17 charles17 2020-12-29 08:16:03 UTC
*** Bug 759448 has been marked as a duplicate of this bug. ***
Comment 18 charles17 2020-12-30 07:55:13 UTC
(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.
Comment 19 junkmailnotread 2021-04-18 15:29:31 UTC
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"
Comment 20 Cedric Sodhi 2021-04-18 15:49:22 UTC
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.
Comment 21 junkmailnotread 2021-04-18 22:13:58 UTC
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;
Comment 22 sulfinu 2021-04-23 16:34:18 UTC
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.