The topmost patch on this stack is a fix which unfortunately adds a new public API, in order to prevent a crash in a different API.
The other two patches fix a build failure that occurs with recent versions of Rust.
I expect all three of these patches to be backported to ESR 78.2.0, in which case they will no longer be needed. The first one is not confirmed yet that it will be backported, but I don't expect any difficulty there.
This is the recommended set of configure options with which to build SpiderMonkey 68:
--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 63.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.
--host: This is set to the host triplet name. I'm not entirely sure
if this is strictly necessary.
AUTOCONF: If you make downstream
changes to SpiderMonkey's configure scripts, you will need to have a
build-dependency on autoconf 2.13 (any more recent version will not
work) to regenerate them. You may need to set the AUTOCONF variable on
the configure command line, since different systems have different
program-suffixes for autoconf 2.13. If you didn't make changes but the
build is checking for autoconf 2.13 anyway, you can bypass this check by
configuring with AUTOCONF=autoconf.
You may also want to consider:
--enable-ctypes:
This is not considered core GJS functionality, so no GNOME software
should use it, but it could be interesting for developers. However, I
don't test builds with this option and it's been broken in the past.
--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.)
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.
Thanks,
Philip C
