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.

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.

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

(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.

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?

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?

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

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

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.

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

(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.