libxfce4ui will potentially do Wayland-specific things if GDK_WINDOWING_WAYLAND is defined by Gdk, which happens if Gtk is built with the wayland USE flag. Despite this, it's missing a wayland USE flag of it's own (and the associated dependency on the wayland flag for Gtk). This means that the following sequence of events will produce a broken libxfce4ui (which will for example prevent launching Xfce): 1. Add wayland to your USE flags 2. Run "emerge --deep --verbose --newuse @world" 3. Install Xfce or any program that uses libxfce4ui 4. Remove wayland from your USE flags 5. Run "emerge --deep --verbose --newuse @world" After that, libxfce4ui-2.so will still refer to the "gdk_wayland_display_get_type" symbol, which will no longer exists due to Gtk not having the wayland USE flag set anymore.
I don't see any configure option that would be relevant to this. This is an upstream bug then, isn't it?
There is no configure option, but it does check for the define that Gdk defines (GDK_WINDOWING_WAYLAND), which seems good enough to me in this case.
(In reply to Kacper Słomiński from comment #2) > There is no configure option, but it does check for the define that Gdk > defines (GDK_WINDOWING_WAYLAND), which seems good enough to me in this case. I don't see how to use that to prevent the breakage if libxfce4ui[-wayland] is built against gtk+[wayland].
(In reply to Michał Górny from comment #3) > I don't see how to use that to prevent the breakage if libxfce4ui[-wayland] > is built against gtk+[wayland]. Hmm, good point. I was thinking of having libfxce4ui depend on gtk+ having the same state of the wayland USE flag. Also probably worth noting, the Wayland detection is only there to disable some functionality that's broken under Wayland: #ifdef GDK_WINDOWING_WAYLAND if (GDK_IS_WAYLAND_DISPLAY (gdk_display_get_default ())) { if (startup_notify == TRUE) { /* 'sn_display_new' crashes when used via wayland, so no startup notification support here */ g_warning ("startup notification not supported for wayland sessions"); startup_notify = FALSE; } } #endif
Sounds like they're working around some bug in startup-notification then. Any idea if this bug is still valid? I suppose it kinda sucks to add a dep on conditional symbols over something like this.
Not sure what do to about this. Looking at the source code for libsn, sn_display_new crashes because it unconditionally uses the given X11 display (and immediately goes to work querying atoms without checking if it's valid), so it's not easy to fix there probably, considering the whole lib looks pretty X11-specific.
Just for some further reading: there's all sorts of problems similar to this, unfortunately, see bug 624960 (although the XFCE issue here is actually something concrete instead of gcr etc)
This also affects the new official binpkgs. They have wayland symbols.
(In reply to Xeha from comment #8) > This also affects the new official binpkgs. They have wayland symbols. Which ones, specifically? The same one Kacper reported, or bug 624960 in general?
I suppose this no longer applies to 4.19+ that no longer does automagic Wayland symbols. I suppose the easy way out would be to add IUSE='wayland X' and dep on gtk+[wayland=,X=], though it would be inconvenient for users. The hard way would be to hack it to control the code depending on the flags, and then do gtk+[wayland?,X?].
(In reply to Sam James from comment #9) > (In reply to Xeha from comment #8) > > This also affects the new official binpkgs. They have wayland symbols. > > Which ones, specifically? The same one Kacper reported, or bug 624960 in > general? The same as this one (by Kacper). Updated a node which had the new binpkgs enabled and it broke in the exact same way.
This continues to bit people - someone just hit it on IRC today, and we had https://forums.gentoo.org/viewtopic-t-1168976.html the other day too.
w.r.t. bug 624960 and bug 680496. The current state of affairs is that packages such as libxfce4ui engage in the act of performing automagic dependencies (they automagically depend on gtk+[wayland], to be specific). Result: packages are broken, and leaving packages broken is bad. There are two general possibilities for fixing it: - adding new functionality to EAPI 9 - packages that automagically depend on gtk+[wayland] should have IUSE="wayland" and depend on gtk+[wayland=] to force rebuilds The first option is a great long-term idea, but is not an appropriate solution for making systems correct *today*. It requires a multi-year process to design, agree on, and roll out new functionality across PMS and portage, and in the meantime users are stuck. I propose implementing option 2 and migrating to option 1 as part of bumping individual packages to EAPI=9 (whenever that happens).
Do not forget that X is the very same case, so you would need [X=] as well in many cases then, and that's probably a fun experience to a user that wants to get rid of legacy X stuff gradually.
(In reply to Mart Raudsepp from comment #14) > Do not forget that X is the very same case, so you would need [X=] as well > in many cases then, and that's probably a fun experience to a user that > wants to get rid of legacy X stuff gradually. USE=X is in the base desktop profile (unlike USE=wayland), so it's not so bad.
But USE=X is the one that people will actually be disabling once we make it viable in terms of other matters. Though granted, not in the context of XFCE4, where also gtk+[X] is hard required in libxfce4ui per the code I looked at. As for wayland, I would be happy to just package.use.force that one on gtk at this point.
(In reply to Mart Raudsepp from comment #16) > But USE=X is the one that people will actually be disabling once we make it > viable in terms of other matters. Though granted, not in the context of > XFCE4, where also gtk+[X] is hard required in libxfce4ui per the code I > looked at. Fair point, yeah. > > As for wayland, I would be happy to just package.use.force that one on gtk > at this point. This would WFM. Toggling it is of dubious value, right? Plus, we have precedent for p.use.force for ABI "breaks" like this.
I mostly fear for the outcry of those still stuck with X11 desktops, I suppose.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cec63c55db0dded229ba78395830af7fb7e0bed0 commit cec63c55db0dded229ba78395830af7fb7e0bed0 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-05-19 18:01:45 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-08-06 00:18:30 +0000 xfce-base/libxfce4ui: prevent automagically building against gtk[wayland] The upstream code checks whether GDK_WINDOWING_WAYLAND is defined by the gtk headers, and if so will compile against the wayland symbols it provides. This means that libxfce4ui built on a system with gtk+[-wayland] will be compatible with anything, but when built on a system with gtk+[wayland], requires that at runtime regardless of USE flag. This cannot be expressed with USE flags. We could bind tightly to whether gtk was built with wayland and arbitrarily restrict libxfce4ui[-wayland] to only build and install on a system with gtk+[-wayland]. But we recently added a hack to gtk itself which allows hiding the automagic macros entirely. Inject this via append-cflags if the USE flags aren't set, to simulate building on a system with more minimal gtk packages. Fixed upstream in: https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/967359624e408365b4c027bab66e737063af604b and hence only worked around for 4.18. Bug: https://bugs.gentoo.org/624960 Closes: https://bugs.gentoo.org/873520 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> xfce-base/libxfce4ui/libxfce4ui-4.18.6-r1.ebuild | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+)
