Re: SpiderMonkey 60

[philip chimento gmail com]

Hi lists,

To follow up to the below message: this is now merged and will appear in the GNOME 3.29.90 release.

There's an upstream tarball hosted at http://ftp.acc.umu.se/pub/gnome/teams/releng/tarballs-needing-help/mozjs/mozjs-60.1.0.tar.bz2 which should be able to be built without any downstream patches. (There are still patches pending review in Mozilla's bug tracker, but they're not required for SpiderMonkey to work correctly.)

Regards,

Philip C

On Sat, Jun 2, 2018 at 5:53 PM <philip chimento gmail com> wrote:

Hi lists,

This is a heads up that I intend to make GJS depend on SpiderMonkey 60 (corresponding with Firefox's extended support release, ESR60) for the upcoming GNOME 3.29.3 (GJS 1.53.3), or otherwise the following .4 release at the latest. Here's the GitLab issue where you can follow along:

https://gitlab.gnome.org/GNOME/gjs/issues/161

The merge request is essentially done, just waiting on some details.

SpiderMonkey 60 can be downloaded here:

http://ftp.mozilla.org/pub/spidermonkey/prereleases/60/

Mozilla has not worked out an automatic release process for SpiderMonkey tarballs yet. However, they are a lot closer than they were for the previous ESR, and tarballs will continue to be published manually at the above location, perhaps outside of the 'prereleases' dir.

Currently it's required to build SpiderMonkey 60 with two patches, which you can find here: https://github.com/ptomato/mozjs/commits/mozjs60

However, these patches have already been merged in Firefox's ESR branch, and will be released in SpiderMonkey 60.1.0. This marks perhaps the first time since SpiderMonkey 17 that no extra patches will be required.

This is the recommended set of configure options with which to build SpiderMonkey 60:

--disable-jemalloc: This one is strictly required, as recent changes have made the jemalloc allocator incompatible with standalone SpiderMonkey.

--with-intl-api: This one is also strictly required, as core functionality of GJS will not work without it.

--enable-posix-nspr-emulation: This one is strongly recommended. Without it, you'll have an unnecessary dependency on NSPR.

--with-system-zlib: This one is also 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 59.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: In the org.gnome.Sdk flatpak manifest we set this to i586-unknown-linux-gnu for i386, and arm-unknown-linux-gnueabi for arm. 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.

Lastly, I'd appreciate your feedback on how to make this transition smoother than it was last time from SpiderMonkey 38 to 52.

Thanks,

Philip C