Right now portage have only dev-perl/JavaScript-SpiderMonkey-0.200.0, which isn't compatible with current stable dev-lang/spidermonkey-1.8.2.15. I've made a patch to make it compatible with 1.8.2.15. It works both with JavaScript::SpiderMonkey-0.20 and -0.21 (latest module version, not available in portage, ebuild generated by g-cpan). But in dev-lang/spidermonkey-1.8.5-r1 there are a lot of other incompatible changes and this break dev-perl/JavaScript-SpiderMonkey once again. I've made a patch to make it compatible with 1.8.5. Probably this patch is incomplete, because trying to use JavaScript::SpiderMonkey with 1.8.5 result in perl crash. But same patch works fine with 1.8.2.15, so chances are bug in spidermonkey-1.8.5 and not in that patch. There is also one more issue, which is amd64-specific (using 1.8.2.15). On amd64 JavaScript-SpiderMonkey doesn't pass it's own tests. I've made small test script which demonstrate this issue. It work ok on x86: $ ./spidermonkey.pl 427221856 at ./spidermonkey.pl line 11. 427283328 at ./spidermonkey.pl line 12. Use of uninitialized value $val in concatenation (.) or string at /usr/lib/perl5/vendor_perl/5.12.4/i686-linux/JavaScript/SpiderMonkey.pm line 262. rc=1 err= and fail on amd64: $ ./spidermonkey.pl 14228996273856 at ./spidermonkey.pl line 11. -230287056 at ./spidermonkey.pl line 12. Dispatcher: Can't find mapping for function 1422899627212814228996272128 'myfunc' at /usr/lib64/perl5/vendor_perl/5.12.4/x86_64-linux/JavaScript/SpiderMonkey.pm line 255 At a glance - looks like some 32-bit overflow happens. Here is test script: #!/usr/bin/perl use JavaScript::SpiderMonkey; my $js = JavaScript::SpiderMonkey->new(); $js->init(); my $obj = $js->object_by_path('myobj'); warn $$obj; warn $js->function_set('myfunc', sub {}, $obj); my $rc = $js->eval('myobj.myfunc();'); warn "rc=$rc err=$@\n"; Because of this issue we don't have working JavaScript-SpiderMonkey on amd64.
Created attachment 302153 [details, diff] compatiblity with 1.8.2
Created attachment 302155 [details, diff] compatibility with 1.8.5
This is an excellent attempt at porting the code for JavaScript::SpiderMonkey to the newer 1.8.5+ API. Unfortunately, right now it is only a partial port; it looks like you have done a lot of necessary work in the '.xs' files (which is great as I know nothing about those), however spidermonkey-1.8.5 requires significant changes to the C code as well as it is in fact a very different API and not compatible with 1.8.2.15 or earlier. I'll look into it though, hopefully it will not be too difficult to finish the port to 1.8.5
Created attachment 326230 [details] support all spidermonkeys OK, so the following patch provides something that works with 1.8.5 on amd64. All tests pass, also the "correct" results from the example provided earlier occur on amd64. Another patch will follow with necessary changes to the ebuild
(In reply to comment #4) > Created attachment 326230 [details] > support all spidermonkeys > > OK, so the following patch provides something that works with 1.8.5 on > amd64. All tests pass, also the "correct" results from the example provided > earlier occur on amd64. > > Another patch will follow with necessary changes to the ebuild Actually no it won't; only necessary changes are what is needed to apply the patch in src_prepare. Also, tests pass with perl[-ithreads], I guess USE=ithreads was only needed to make it possible to debug with gdb.
On hardened system it doesn't work. :( When any test is run I got segfault and this in logs: 2012-10-10_22:33:32.27125 kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/perl5.12.4[perl:30403] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:17666] uid/euid:0/0 gid/egid:0/0 2012-10-10_22:33:32.27128 kern.info: perl[30403]: segfault at 10 ip 00006eef54058394 sp 000079b07b67c940 error 4 in libpthread-2.15.so[6eef5404e000+18000] 2012-10-10_22:33:32.27128 kern.alert: grsec: Segmentation fault occurred at 0000000000000010 in /usr/bin/perl5.12.4[perl:30403] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:17666] uid/euid:0/0 gid/egid:0/0 Perl built without ithreads: [ebuild R ] dev-lang/perl-5.12.4-r1 USE="berkdb gdbm -build -debug -doc -ithreads" 0 kB
(In reply to comment #6) > On hardened system it doesn't work. :( When any test is run I got segfault > and this in logs: > > 2012-10-10_22:33:32.27125 kern.alert: grsec: denied RWX mmap of <anonymous > mapping> by /usr/bin/perl5.12.4[perl:30403] uid/euid:0/0 gid/egid:0/0, > parent /bin/bash[bash:17666] uid/euid:0/0 gid/egid:0/0 > 2012-10-10_22:33:32.27128 kern.info: perl[30403]: segfault at 10 ip > 00006eef54058394 sp 000079b07b67c940 error 4 in > libpthread-2.15.so[6eef5404e000+18000] > 2012-10-10_22:33:32.27128 kern.alert: grsec: Segmentation fault occurred at > 0000000000000010 in /usr/bin/perl5.12.4[perl:30403] uid/euid:0/0 > gid/egid:0/0, parent /bin/bash[bash:17666] uid/euid:0/0 gid/egid:0/0 > > Perl built without ithreads: > [ebuild R ] dev-lang/perl-5.12.4-r1 USE="berkdb gdbm -build -debug > -doc -ithreads" 0 kB The '.xs' code is somewhat simplistic (and possibly a bit hacky), so probably it isn't compatible with hardened; I don't have a hardened system to test. If you enable the 'debug' use flag on spidermonkey, this will add a massive amount of 'assert' logic which may help you track down the issue.
(In reply to comment #7) > The '.xs' code is somewhat simplistic (and possibly a bit hacky), so > probably it isn't compatible with hardened; I don't have a hardened system I don't think this issue have anything with .xs. RWX mmap is most likely related to things like JIT. dev-lang/spidermonkey-1.8.5-r1 doesn't provide "jit" USE-flag, is it possible to build it without JIT?
I've just tried dev-lang/spidermonkey-1.8.7. It doesn't provide jsautocfg.h, so it should be removed from @c_header_files in Makefile.PL, but looks like JavaScript-SpiderMonkey-0.210.0 pass all tests with 1.8.7 both without "jit" USE-flag and with it (I still got a lot of "kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/perl5.12.4" in logs, but it doesn't try to kill perl process anymore and thus doesn't break tests). BTW, can you explain why exacly you've hardmasked 1.8.7? On my system only package which depend on spidermonkey is polkit, and it builds with 1.8.7 just fine.
The hard-mask for 1.8.7 is because there are plenty of packages still that depend on spidermonkey which will not build against this version. This has to do with the fact that the whole library name changed (from mozjs185 to mozjs187) and so all build systems need to be patched (even those using pkg-config). Until that work is completed, 1.8.7 has to stay masked.
Created attachment 326306 [details, diff] use pkgconfig to get correct info from newer spidermonkeys With the addition of 'dev-perl/extutils-pkgconfig' to DEPEND in the ebuild, this patch will use pkg-config to determine the correct libs and cflags to use for linking against spidermonkey-1.8.5 and newer. Please test and check if this works fine for you; I think it is pertinent to do this going forward. By skipping the old checks for headers etc it overcomes the @c_header_files issue while keeping that code in place for searching for older spidermonkeys (as there are still cases where users have masked anything newer than 1.7, this is important).
(In reply to comment #9) > I've just tried dev-lang/spidermonkey-1.8.7. It doesn't provide jsautocfg.h, > so it should be removed from @c_header_files in Makefile.PL, but looks like > JavaScript-SpiderMonkey-0.210.0 pass all tests with 1.8.7 both without "jit" > USE-flag and with it (I still got a lot of "kern.alert: grsec: denied RWX > mmap of <anonymous mapping> by /usr/bin/perl5.12.4" in logs, but it doesn't > try to kill perl process anymore and thus doesn't break tests). Could you try pax-marking the SpiderMonkey.o file and see if that keeps perl from being killed? the polkit ebuild has an example of this.
+ 11 Oct 2012; Ian Stakenvicius <axs@gentoo.org> +files/mozjs185.patch, + JavaScript-SpiderMonkey-0.200.0.ebuild: + support spidermonkey-1.8.5 and newer, fix support for x86_64 (bug 404129) + Too much being done on this bug already; if there's a better fix for hardened than using spidermonkey-1.8.7 , that can go in a new bug.
