Bug#1125927: /usr/bin/gnome-shell: symbol lookup error: /usr/lib/aarch64-linux-gnu/libgjs.so.0: undefined symbol: __aarch64_ldadd4_acq_rel, version mozjs_140

[Simon McVittie]

Control: reassign -1 libgjs0
Control: forcemerge 1125777 -1
Control: affects -1 + gnome-shell src:gnome-shell
Control: retitle -1 symbol lookup error on arm64 after recent binNMUs: undefined symbol: __aarch64_ldadd4_acq_rel, version mozjs_140

On Sun, 18 Jan 2026 at 23:36:04 +0100, Johannes Schauer Marin Rodrigues wrote:
>/usr/bin/gnome-shell: symbol lookup error: /usr/lib/aarch64-linux-gnu/libgjs.so.0: undefined symbol: __aarch64_ldadd4_acq_rel, version mozjs_140

This is arm64-specific (so not really "unusable for most users" given 
the relative popularity of x86 and arm64), and appears to be resolvable 
without source-code changes by rebuilding gjs against the updated mozjs.  
I assume from its name that the __aarch64_ldadd4_acq_rel symbol is 
arm64-specific, and there is presumably some quirk of the relevant 
libraries' ABIs that means gjs picks it up from mozjs rather than from 
some compiler-runtime library.

When the mass-binNMU to rebuild with GCS on arm64 is no longer carrying 
out a denial of service attack on ftp.debian.org, I believe the best 
solution will be to do a sourceful upload of src:mozjs140 to have a new 
version number to depend on (presumably either 140.6.0-1.1, 140.6.0-2 or 
140.7.0-1), possibly with Breaks on libgjs0 (<< 1.86.0-3.1) [arm64] to 
help upgrades from trixie; and then an upload of src:gjs with an extra 
Build-Depends on libmozjs-140-dev (>= 140.6.0-1.1) [arm64] to make sure 
it's on the right side of the transition.

If an arm64 porter is in a hurry to do those uploads, please go ahead 
(consider this to be GNOME team permission to do them as porter uploads 
without using DELAYED, if that helps). Or as a stopgap solution, gjs 
could be binNMU'd by someone who is on the appropriate ACLs (I am not).

Or, otherwise, someone from the GNOME team will get there when we get 
there.

     smcv