SpiderMonkey: bundled vs system-provided

hircus · Post by **hircus** » Tue Sep 15, 2009 2:02 am

Hello,

Is there any specific reason why Oolite bundles its own SpiderMonkey? Is it just for convenience, or are there deeper reasons?

The reason I'm asking is that I'm packaging Oolite for Fedora (yes, we're finally getting GNUstep packages!) and for security reasons, we frown on packages that bundle their own copies of libraries already shipped with the distribution.

I could start tinkering with the make files and find out the hard way, but surely asking first is the easier way to go...

Thanks,

--
Michel

Post by **another_commander** » Tue Sep 15, 2009 6:09 am

Oolite requires that the C_STRINGS_ARE_UTF8 macro be defined in SpiderMonkey in order to have UTF8 support. This is the main reason to the best of my knowledge and, as far as I know, standard SpiderMonkey is built without the above macro defined. Oolite has internal checks for it and will bail out if it does not find a conformant libjs.

In addition to the above, there are a couple more requirements, which are described inside the bail out message itself, found in OOJavaScriptEngine.m, -init method:

Code: Select all

if (!JS_CStringsAreUTF8())
	{
		OOLog(@"script.javaScript.init.badSpiderMonkey", @"SpiderMonkey (libjs/libmozjs) must be built with the JS_C_STRINGS_ARE_UTF8 macro defined. Additionally, JS_THREADSAFE must be undefined and MOZILLA_1_8_BRANCH must be undefined.");
		exit(EXIT_FAILURE);
	}

but as you see, the actual check is for the UTF8 support.

hircus · Post by **hircus** » Tue Sep 15, 2009 8:43 am

another_commander wrote:
as far as I know, standard SpiderMonkey is built without the above macro defined.

Ah, so that's why. I might have asked this before, since this somehow rings a bell. So the next question is, is there any possible downside to having the macro defined in standard SpiderMonkey? If there is none, I could just ask our xulrunner maintainer to have the macro definition enabled.

Also, not having touched GNUmakefiles much myself, I'm assuming it's not that hard to switch to using system SpiderMonkey -- but could someone more familiar with the build process make it so that which SM is used can be swiched with an environment variable?

e.g. make SYSTEM_JS=/usr/include/xulrunner-1.9.1/js

hircus · Post by **hircus** » Tue Sep 15, 2009 8:52 am

hircus wrote:
So the next question is, is there any possible downside to having the macro defined in standard SpiderMonkey? If there is none, I could just ask our xulrunner maintainer to have the macro definition enabled.

Answering myself: no. Let's hope I could get an exception from the Fedora packaging folks, otherwise our official Oolite builds will be stuck at 1.65

Though in that case, I *could* provide a third-party build, akin to the Ubuntu build that currently exists...

JensAyton · Post by **JensAyton** » Tue Sep 15, 2009 1:30 pm

Oolite’s JavaScript engine definitely needs upgrading. As far as I recall, JS_THREADSAFE involves minor API changes, and it could probably be updated for both. JS_C_STRINGS_ARE_UTF8 is a bigger problem.

The bundled version is there in part for consistency, and in part because there is no sane build system for upstream Spidermonkey under Mac OS X (don’t know about Windows).

The bundled version is also old – version 1.7 – and needs to be upgraded for 1.9/TraceMonkey before next stable, hopefully in time for 1.74. Since this is essentially a complete reimplementation, my previous Xcode project doesn’t work, and there are presumably API issues as well. (There were some last time I tried to upgrade, to 1.8, which is why MOZILLA_1_8_BRANCH is mentioned in the message.)

In short: ideally, Oolite would be building against an up-to-date Spidermonkey, and a system one if there is such a thing. But no UTF-8 support is unacceptable.

Post by **Kaks** » Tue Sep 15, 2009 8:22 pm

Well, in windows there's m$ windows scripting host, a severely security challenged implementation of m$'s own jscript & vbscript engines, and we wouldn't really want to touch that with a bargepole!

Quite aside from the fact it's not quite compliant with the ecmascript specifications, most windows based security programs tend to consider a program trying to talk to it as a virus, and quite rightly so!

JensAyton · Post by **JensAyton** » Tue Sep 15, 2009 8:37 pm

I hope no-one’s suggesting using different JavaScript engines on different systems. That way lies madness (and three more years of development).

Post by **Kaks** » Tue Sep 15, 2009 8:43 pm

Seriously, NO!

...but that's what hircus seems to imply with his initial post!

JensAyton · Post by **JensAyton** » Wed Sep 16, 2009 6:44 am

There’s a vast difference between using a system-provided Spidermonkey and using a system-provided completely different JS engine. :-)

zevans · Post by **zevans** » Thu Sep 17, 2009 1:25 am

Mmm, this seems quite similar to the upstream Debian debate, which I ran away from quite quickly after the initial idea of contacting the 1.65 packager to see what was what. Maybe it's worth another go at that now Getafix has updated the Linux package build(s) a bit...

JensAyton · Post by **JensAyton** » Fri Sep 25, 2009 11:00 am

I’ve written up a summary on the Fedora issue tracker.