This is a notice that GJS 1.85.2, scheduled to be included in GNOME 49.beta, will depend on SpiderMonkey 140 (corresponding with Firefox’s extended support release, ESR140).
Mozilla has not worked out an automatic release process for SpiderMonkey tarballs yet. The official recommendation is to use the Firefox ESR140 source tarball. More information can be found here, at Building SpiderMonkey (note these are the build instructions for the previous ESR128, but they are similar.)
The 140.1 release of SpiderMonkey had several bugs in it that make it unsuitable for use with GNOME. You will need to apply two patches:
-
⚙ D256360 Bug 1973993 - Install ProfilingCategoryList.h into both the js/ directory and the toplevel include directory r=#spidermonkey-reviewers (will be patched in 140.2, to be released 2025-08-19)
-
Bug 1973994 - mozjs-140.pc does not contain -DXP_UNIX on Linux · ptomato/mozjs@9aa8b4b · GitHub (temporary patch until Mozilla fixes the issue)
For reference, you will be able to find the set of patches that I build with in Commits · ptomato/mozjs · GitHub.
This is the recommended set of configure options with which to build SpiderMonkey 140:
-
--disable-jemalloc
: This one is strictly required, as the jemalloc allocator is incompatible with standalone SpiderMonkey. -
--with-intl-api
: This one is also strictly required, as core functionality of GJS will not work without it. -
--with-system-zlib
: This one is strongly recommended. Without it, you’ll build SpiderMonkey’s internal copy of zlib, which shouldn’t be necessary as most if not all systems include a suitable shared library. -
--with-system-icu
: This one is recommended, but at least ICU 76.1 is required. If that’s not possible on your platform, then you can use--without-system-icu
to build SpiderMonkey’s internal copy instead.
You may also want to consider --enable-debug
: Never, ever ship a libmozjs with this option in production, as the performance is severely degraded. However, if your platform allows for such a thing, then you might consider shipping a separate debug-enabled package that conflicts with the main package, since the debug option makes it significantly easier to develop with SpiderMonkey and diagnose crashes that might happen on user machines. (A complication is that SpiderMonkey’s ABI is different between debug and non-debug, so a separate GJS package would also be required. GJS’s ABI is the same in both cases.)
For reference, here is how SpiderMonkey is configured in the GNOME SDK: elements/sdk/mozjs.bst · 522727dc64d820d524331bccd0153ba93e52556f · GNOME / gnome-build-meta · GitLab
If you run into build problems with SpiderMonkey on your platform, please open a bug on bugzilla.mozilla.org and CC me. If you can provide a patch that would be great. Mozilla has a review and backport process that’s a bit mystifying for outsiders, and I can help move your patches through it.