spidermonkey: update to 1.8.5

[ryandesign@…]

spidermonkey should be updated to 1.8.5:

​https://developer.mozilla.org/En/SpiderMonkey/1.8.5

[segal@…]

Any status update on this ticket?

[dargo@…]

+1 on this. The current version is dated from 2007-10-03

[snc@…]

This update is requisite for edbrowse (3.4.8).

[snc@…]

Adding other maintainers whose ports depend on spidermonkey. Can anyone verify that their ports don't break via a naive upgrade of spidermonkey?

[ryandesign@…]

MongoDB 2.0.5 still does not support SpiderMonkey 1.8.5; see upstream bugs ​2887 and ​4870 which have some patches but which have not been accepted. 2887 says they might switch from SpiderMonkey to v8 in the future. Meanwhile, as comment:3 says, SpiderMonkey 1.8.5 is required for edbrowse 3.4.8, and probably other programs.

The ​SpiderMonkey 1.8.5 release notes say "SpiderMonkey 1.8.5 is not binary-compatible with previous releases, nor is it source-code compatible" and also "SpiderMonkey embedders should also be aware that ... Mozilla has no plans to keep the JSAPI, nor the JSDBGAPI stable for embedders. We have chosen to concentrate on performance and correctness as primary concerns instead." They even have separate version numbers for each version of SpiderMonkey—it's "SpiderMonkey 1.8.5 1.0.0" for example. For these reasons it might be smart for us to have separate SpiderMonkey ports for each version of SpiderMonkey. That way each other port that uses SpiderMonkey can decide if and when to upgrade to newer versions.

Here's a patch that creates a new spidermonkey185 port. They now use a configure script, so I began from the assumption that our existing patches and workarounds were no longer needed and cleared them away. I had to add back in a patch to fix the creation of the library symlinks when using DESTDIR, and I patched where the headers are installed so as to include the version number in the path. The idea to name the include directory "mozjs185" came from the config.m4 file of php-spidermonkey 1.0.0 which looks for a directory of that name, as one of the possibilities. Because the new js-config script that gets installed also does not have a version number in its name, and it doesn't work right on Darwin, I decided to just delete it and require people to use pkg-config instead.

One remaining outstanding issue is that I cannot get it to build universal (using either the default universal variant or the muniversal portgroup), nor for a non-default build_arch. This is a step backward from the existing spidermonkey port but I don't know how to resolve it right now.

[snc@…]

Replying to ryandesign@…:

One remaining outstanding issue is that I cannot get it to build universal (using either the default universal variant or the muniversal portgroup), nor for a non-default build_arch. This is a step backward from the existing spidermonkey port but I don't know how to resolve it right now.

Do you mean it never builds the requested architecture, so you're left with two x86_64 builds rather than an x86_64 and i386?

[ryandesign@…]

It either fails at configure time (regular universal variant):

checking for the size of void*... configure: error: No size found for void*

Or at build time (muniversal portgroup or non-default build_arch):

nanojit/Containers.h:164: error: integer constant is too large for ‘long’ type

I also note that in include/mozjs185/js-config.h there is this problematic-looking line:

#define JS_BYTES_PER_WORD 8

That looks like something that would have to be merged with muniversal, or manually patched with one of our ubiquitous ed scripts.

I'm not terribly fussed about this right at this second since we're not removing the existing spidermonkey port. It's just something we'd want to fix eventually.

[rudloff@…]

Cc Me!

[nicholas@…]

Had to remove --enable-threadsafe from the configure args to build successfully on ppc64.

Edit: Please disregard my previous comment; spidermonkey builds just fine without --enable-threadsafe as long as you're not doing something stupid.

[cal@…]

MongoDB seems to have moved off SpiderMonkey or shipts its own version. Anything else holding off this upgrade?

[cal@…]

Here's a version of the patch that applies cleanly against the current version of the Portfile

[ryandesign@…]

The mongodb port still uses the spidermonkey port; it doesn't use the bundled copy of spidermonkey or most of the other libs it bundles. If mongodb now supports v8, and specifically the version of v8 that we have in MacPorts, then we could switch the mongodb port to that. That would be a separate ticket.

There's still the question about how to make spidermonkey 1.8.5 build universal.

[ryandesign@…]

Replying to ryandesign@…:

If mongodb now supports v8, and specifically the version of v8 that we have in MacPorts, then we could switch the mongodb port to that. That would be a separate ticket.

Done as part of #38445.

[egall@…]

Cc Me!

[gui_dos@…]

The .diff by cal@… is missing the patch files.

Without them it is not possible to compile Gjs: I submitted a prelminary port with #38705

[cal@…]

r105018. On how to compile spidermonkey universal, I have no idea; but having the port in the first place is better than waiting for some deity to appear and fix it, especially since universal's importance is falling now that a lot of systems only use x86_64 anyway.