Wayland build of gpbs omits xpbs.m and leaves NSPasteboard disconnected from the system clipboard

[danjboyd]

Summary

A libs-back build configured for --enable-server=wayland can produce a gpbs binary that is not connected to the desktop clipboard.

On my Linux/Wayland setup, GNUstep apps then see an empty NSPasteboard and disable Paste even though the system clipboard is populated.

The issue appears to be that Tools/GNUmakefile only includes xpbs.m when BUILD_SERVER == x11, while configure.ac allows --enable-server=wayland and Tools/gpbs.m still expects an XPbOwner/Win32PbOwner style backend.

Environment

• libs-back master at bf3b3ced525f08415a20d109f05be1f91492414c
• Debian trixie
• XDG_SESSION_TYPE=wayland
• observed with a user-installed gpbs built from current upstream master

Reproduction

1. Build/install libs-back from current master with --enable-server=wayland.
2. Start a GNUstep app that uses NSPasteboard.
3. Copy text into the system clipboard.
4. Attempt to paste in the GNUstep app.

Expected Behavior

GNUstep apps should see the system clipboard contents through NSPasteboard, and Paste should be enabled.

Actual Behavior

• wl-paste shows the expected clipboard text.
• xclip -selection clipboard -o also shows the expected clipboard text.
• A small GNUstep/AppKit NSPasteboard probe sees no pasteboard types / no string content.
• GNUstep apps disable Paste because AppKit believes there is nothing pasteable.

In my local testing, the Wayland-built gpbs could still round-trip pasteboard contents between GNUstep processes, which suggests it is operating as an internal pasteboard only rather than bridging to the desktop clipboard.

Analysis

These pieces seem to line up:

• configure.ac allows --enable-server=wayland
• Tools/gpbs.m selects XPbOwner or Win32PbOwner
• Tools/GNUmakefile only adds xpbs.m when BUILD_SERVER == x11

That means a Wayland build can produce a gpbs binary without the X clipboard owner implementation that gpbs otherwise uses.

Minimal Local Fix

For my setup, the smallest working fix was to compile xpbs.m into gpbs for Wayland builds too:

diff --git a/Tools/GNUmakefile b/Tools/GNUmakefile
index 29b1be1..c0b7a3a 100644
--- a/Tools/GNUmakefile
+++ b/Tools/GNUmakefile
@@ -46,7 +46,7 @@ MAN1_PAGES += font_cacher.1
 endif
 endif
 
-ifeq ($(BUILD_SERVER),x11)
+ifneq ($(filter $(BUILD_SERVER),x11 wayland),)
 gpbs_OBJC_FILES += xpbs.m 
 ifeq ($(BACKEND_BUNDLE),yes)
 font_cacher_OBJC_FILES += XGCommonFont.m

With that patch applied, a Wayland-built gpbs can see the system clipboard again on my machine and paste works normally in GNUstep apps.

I do not know whether the correct long-term solution is a Wayland-native clipboard owner, but it seems undesirable for a Wayland build to silently produce a clipboard-less gpbs.

Patch Artifact

• Public gist with the exact local patch: https://gist.github.com/danjboyd/309380dec1afbe3f2dc1d471b2ca83a1