1746715 - libxul.so: undefined symbol: gdk_wayland_window_get_wl_surface

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P5)

Description

[drJeckyll]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

Latest Firefox Nightly fails to start with:

XPCOMGlueLoad error for file /opt/firefox/libxul.so:
/opt/firefox/libxul.so: undefined symbol: gdk_wayland_window_get_wl_surface
Couldn't load XPCOM.

It was working until 97.0a1 (2021-12-15) (64-bit). Downgrading make firefox run again.

Comment 1

[Matthew Turnbull [Bluefang]]

This is what I found:

2:21.94 INFO: Narrowed integration regression window from [305bfa67, e5de1d09] (3 builds) to [9782e9bd, e5de1d09] (2 builds) (~1 steps left)
2:21.94 INFO: No more integration revisions, bisection finished.
2:21.94 INFO: Last good revision: 9782e9bdd3838aeb5d0ecea508fe744110543fd4
2:21.94 INFO: First bad revision: e5de1d0915a419d409bf9bbe8573c1e9d4b0bc47
2:21.94 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9782e9bdd3838aeb5d0ecea508fe744110543fd4&tochange=e5de1d0915a419d409bf9bbe8573c1e9d4b0bc47

Bug 1359918 - Add -Wl,-z,now Linker Flags.

man ld:

-z now : When generating an executable or shared library, mark it to tell the dynamic linker to resolve all symbols when the program is started, or when the shared library is loaded by dlopen, instead of deferring function call resolution to the point when the function is first called.

So, technically, it's doing what it's supposed to. However, it breaks compatibility with GTK built without Wayland support.

Also worth noting that mozregression-gui did not work for bisecting this, since it looks like the packaged libgtk-3 was masking the system libgtk-3.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Does it help if you add dummy prototype to https://searchfox.org/mozilla-central/source/widget/gtk/mozwayland/mozwayland.c ?

Comment 3

[Matthew Turnbull [Bluefang]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Does it help if you add dummy prototype to https://searchfox.org/mozilla-central/source/widget/gtk/mozwayland/mozwayland.c ?

Was that a question for me? I'm using Mozilla provided nightly builds. I'm not a c/gtk dev, so these changes are definitely outside of my wheelhouse.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1746715 [Wayland] Link gdk_wayland_window_get_wl_surface dynamically, r?rmader

Comment 5

[Matthew Turnbull [Bluefang]]

Since I don't have a phabricator account - for completeness, I see libxul referencing these symbols:

$ nm -D libxul.so | grep wayland
U gdk_wayland_device_get_wl_pointer
U gdk_wayland_display_get_wl_compositor
U gdk_wayland_display_get_wl_display
U gdk_wayland_window_get_wl_surface

Presumably, it was just aborting on the first encountered unresolved symbol, but I expect these are all problematic. Not sure if there are other impacted symbols. Is there a way to get firefox/ldd to spit out unresolved symbols?

Comment 6

[Martin Stránský [:stransky] (ni? me)]

In such case se can use dummy prototypes as we have for other wayland code. Mike, how important are the '-Wl,-z,now' linker flags?

Comment 7

[Mike Hommey [:glandium]]

It depends if we've seen performance regressions from the landing, which I don't know yet.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Okay, let me know if you need such patch for '-Wl,-z,now' flags.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

This was fixed by backout for 97, but leaving this bug open for whatever fix eventually needs to land for bug 1359918 to re-land.

Comment 10

[James Graham [:jgraham]]

Is this still an S2 if we backed out the original patch?

Comment 11

[Martin Stránský [:stransky] (ni? me)]

(In reply to James Graham [:jgraham] from comment #10)

Is this still an S2 if we backed out the original patch?

I don't think so.

Comment 12

[Seirdy]

Curious: which distributions still build GTK3 without Wayland support? If the distros impacted when this issue was filed have since switched to building GTK with Wayland support, then this may be due for a second try.

Comment 13

[Matthew Turnbull [Bluefang]]

Wayland is still entirely optional in Gentoo, and that probably won't change any time soon. Mint also just barely announced they had begun working on Wayland support, with a target of defaulting to Wayland in 2026.

I suspect LTS versions of various distros may also have spotty Wayland support, but I haven't done the research.

As far as desktop environments go, XFCE and Mate are still a work in progress, and I haven't seen any work started in Cinnamon yet (but maybe they were waiting for the Mint announcement).

--

Was there any investigation/work done to see if it was viable to have dummy implementations when these symbols aren't available? That seems like a good direction to go while there are still desktop environments and distributions that don't (or optionally) have Wayland support.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

(In reply to Matthew Turnbull [Bluefang] from comment #13)

Was there any investigation/work done to see if it was viable to have dummy implementations when these symbols aren't available? That seems like a good direction to go while there are still desktop environments and distributions that don't (or optionally) have Wayland support.

I think there are bugs with higher priority worked on but patches are welcomed here.

Comment 15

[mf2]

So what can I do as a Gentoo user about this? Hack together some kind of LD_PRELOAD that exports these symbols or recompile my whole system with wayland support, which I would rather not do?

Comment 16

[Mike Hommey [:glandium]]

Attachment: Bug 1746715 - Add the GDK wayland symbols to the mozwayland library.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ca3d1972e2d
Add the GDK wayland symbols to the mozwayland library. r=stransky

Comment 18

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/1ca3d1972e2d