Bug#1141558: libgjs.so.0: undefined symbol: __aeabi_uidivmod, version mozjs_140

[Simon McVittie]

Package: libgjs0
Version: 1.88.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-arm at lists.debian.org, mozjs140 at packages.debian.org
User: debian-arm at lists.debian.org
Usertags: armhf
Control: affects -1 src:ostree

src:ostree runs some build-time test scripts written in JavaScript, 
using the gjs interpreter. In 
https://buildd.debian.org/status/fetch.php?pkg=ostree&arch=armhf&ver=2026.2-1&stamp=1783287267&file=log:

>ERROR: tests/test-core.js
>=========================
>
>gjs: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgjs.so.0: undefined symbol: __aeabi_uidivmod, version mozjs_140
>ERROR: tests/test-core.js - missing test plan
>ERROR: tests/test-core.js - exited with status 127 (command not found?)

It looks as though recompiling src:mozjs has caused it to lose a symbol 
that it previously exported, with a side-effect of making libgjs 
unusable on armhf. Other architectures seem fine.

The name __aeabi_uidivmod looks like a toolchain thing rather than part 
of mozjs itself, and 
https://codesearch.debian.net/search?q=__aeabi_uidivmod&literal=1 
indicates that it's part of libgcc. Has there perhaps been a gcc or LLVM 
behaviour change in how this symbol is expected to be handled? Maybe it 
was previously copied (statically linked) into libmozjs, but is now 
imported from the shared libgcc? (Note that libmozjs is partly Rust, if 
that matters.)

If this is a toolchain behaviour change, a simple rebuild of src:gjs 
might address this. (Or not, I don't know.)

    smcv