Allow linking to system spidermonkey library

I'm a bit hesitant to add the option to link against the system library without a check to see if it was compiled with JS_THREADSAFE defined. I had issues when I tried linking against system libraries before.

If/when I upgrade the spidermonkey version to 1.8 I think this concern goes away because the single threaded API is identical to the threaded version.

I'm also not even sure that the OS X port includes a pkg-config file either.

I've added a check for -DJS_THREADSAFE in the following commit: http://github.com/malept/python-...

With regards to the OS X port, I don't know either. I can't test this myself, as I do not own a Mac.

Matt,

Can you check your system's libmozjs library to see if it exports a function _js_DefineProperty?

$ nm /path/to/libmozjs.so | grep _js_DefineProperty

The port version of libmozjs that comes with Xulrunner doesn't appear to be exporting it. Granted it is an internal API I'm dipping into (that'll be public in 1.8 ;)

Also, I'll push my changes that work without --system-library so you can double check them on your machine.

I'm not entirely sure who Matt is :)

Seriously though, it looks like only JS_DefineProperty is consistently exported in all of the versions of spidermonkey that I have lying around on my system.

I had to use readelf -s instead of nm to search for the symbol. Unless noted, the implementations in question are compiled from source.

• spidermonkey 1.7.0: js_DefineProperty JS_DefineProperty

• Firefox 2.0.x: JS_DefineProperty

• XULRunner 1.8.x: JS_DefineProperty

• XULRunner 1.9.x: JS_DefineProperty

*Firefox 3.0.x (binary package from mozilla.com): JS_DefineProperty

Whoops, I somehow managed to s/Mark/Matt/ even though I double checked right before writing that. :/

Does the new version of python-spidermonkey work for you then? If so, something is definitely weird because it doesn't look like it should.

The function I need specifically is js_DefineProperty (note the lowercase js) because it allows for a jsval to specify the property id instead of requiring a string or number.

I cannot for the life of me figure out how it's even running for you if you're linking against a library that doesn't have it. The docs say that 1.8 is supposed to have a JS_DefinePropertyById but I can't even find that to #ifdef to the correct call.

Ah, I see. I adjusted my LDFLAGS so that it links with --no-undefined, and obviously, it couldn't find js_{Define,Delete,Get,Set}Property. (Note: by default, I link to XULRunner-1.9.0.x.)

When I ran the testsuite, it segfaulted on test-context.test_exceed_memory, at the following line: 0xb7607ccc in branch_cb (jscx=0x86281e0, script=0x862ba78) at spidermonkey/context.c:194 194 if(pycx->max_heap > 0 && jscx->runtime->gcBytes > pycx->max_heap)

There's JS_DefinePropertyWithTinyId (available in all of the versions I have), but I don't know if that works for you.

Hmmm. This is starting to get fairly complicated. What was the original motivation to link against a system library instead of using the linked in version?

This article was my main motivation:

http://blog.flameeyes.eu/2009/01...

(Short version: if I want to try to add python-spidermonkey to Gentoo, bundled libraries should be avoided whenever possible.)

I'm going to install spidermonkey 1.8.0-RC1 and see if it has the API that python-spidermonkey needs.

Ahh. My current D-Day for removing the internal spidermonkey is when spidermonkey 1.8 hits mac ports. The js_DefineProperty functions are actually public API in that version and I didn't want to have to write a bunch of crappy type enforcement only to rip it out when I had access to a better API.

Once I finish some other work I'll go back to the xulrunner library and try and get a better idea of what's going on.

Mark,

I think I just realized the issue I'm having. I was poking through the strings in libmozjs and I realized that the binary says 1.8.0 (even though the pkg-config says 1.9.0.

I was pretty certain that 1.8.0 was supposed to have those functions I needed so I checked back in the docs and they say they won't be released until 1.8.1.

So until that's released I (which the docs say should be "soon") I think this will have to wait.

Just an update, the mozilla guys say that they're hopefully going to cut an RC in the next week or so. As soon as that's out I'm going to either create a port file or bug the current spidermonkey port maintainer to add one for it. At that point I'll swap out the built in library for a system Spidermonkey at 1.8.1