Last Comment Bug 735599 - (js17src) Create JS 17 source release
(js17src)
: Create JS 17 source release
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Sean Stangl [:sstangl]
:
Mentors:
: 790257 (view as bug list)
Depends on: 852789
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-14 01:53 PDT by drago01
Modified: 2015-01-06 09:54 PST (History)
28 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
backport bug 714312 (1.97 KB, patch)
2012-04-26 03:45 PDT, Landry Breuil (:gaston)
no flags Details | Diff | Splinter Review
filter-out %.$(LIBS_DESC_SUFFIX) (922 bytes, patch)
2012-06-18 11:23 PDT, Jory A. Pratt
no flags Details | Diff | Splinter Review
If available, use SO_VERSION from configure env to set DLL_SUFFIX (534 bytes, patch)
2013-03-16 01:37 PDT, Landry Breuil (:gaston)
no flags Details | Diff | Splinter Review

Description drago01 2012-03-14 01:53:42 PDT
The current spidermonkey package as shipped https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which is what got into Firefox 4. 

There have been a lot of improvements to the javascript engine since then which warrants release a new version.

So can we have a new standalone js release?
Comment 1 David Mandelin [:dmandelin] 2012-03-15 17:07:29 PDT
(In reply to drago01 from comment #0)
> The current spidermonkey package as shipped
> https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which
> is what got into Firefox 4. 
> 
> There have been a lot of improvements to the javascript engine since then
> which warrants release a new version.
> 
> So can we have a new standalone js release?

Wes and I were talking about it recently, but I can't remember where we left it. I think we talked about using the version that went into Firefox 10 ESR. Would that have the new features you want?
Comment 2 drago01 2012-03-16 01:32:29 PDT
(In reply to David Mandelin from comment #1)
> (In reply to drago01 from comment #0)
> > The current spidermonkey package as shipped
> > https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which
> > is what got into Firefox 4. 
> > 
> > There have been a lot of improvements to the javascript engine since then
> > which warrants release a new version.
> > 
> > So can we have a new standalone js release?
> 
> Wes and I were talking about it recently, but I can't remember where we left
> it. I think we talked about using the version that went into Firefox 10 ESR.

Yeah having it based on an ESR make sense.

> Would that have the new features you want?

Yes that should be fine.
Comment 3 David Mandelin [:dmandelin] 2012-03-16 11:22:47 PDT
OK, it might take a while to spin this up, but it's on my list.
Comment 4 drago01 2012-03-16 11:29:15 PDT
(In reply to David Mandelin from comment #3)
> OK, it might take a while to spin this up, but it's on my list.

OK, thanks!
Comment 5 David Mandelin [:dmandelin] 2012-04-03 18:08:56 PDT
Getting ready to work on this. First tiny step: updating title to match what was used last time around in bug 628723.
Comment 6 David Mandelin [:dmandelin] 2012-04-03 18:18:45 PDT
Wes gave me his procedure from last time around. It went something like this:

1. Snapshot the source code. I'll use ESR10.
2. Handpick other patches to land. I'm not sure what we need--ESR10 tends to pick up the security bugs. I could audit them, which might be useful anyway. Otherwise I'll probably just go according to suggestions from embedders. So:
2.1. Audit security fixes looking for anything that didn't land in ESR10. Land anything that looks like it can land there.
2.2. Apply Wes's patch for library names.
3. Build and run the test scripts to make sure everything works
4. Make a tar file and put it out for testing.
5. Wait for feedback and apply it to the result. Keep track of problems people run into upgrading.
6. Make a tar file and put it out as a release.

(these can start as the above are ongoing)
7. Update the release notes:
7.1. Find new, changed, and deleted APIs and list them.
7.2. Find important types that change and document them.
7.3. Document any breakage users found in upgrading
7.4. Document major new engine/language features
Comment 7 David Mandelin [:dmandelin] 2012-04-06 14:41:20 PDT
http://people.mozilla.com/~dmandelin/sm187.tar.gz

Here's a first try. It's very close to the rev named in the README. All I did in addition was:

 - apply a fix for a failing test reress-422269
 - remove a failing test for findReferences-01. This is a test for a "find the GC path to this object" shell function that fails just because of some small formatting differences, and where the bug fix doesn't apply cleanly to ESR10.
 - marked a test regress-80981 as slow, because it is
 - applied Wes's libname-changes.patch (with s/5/7)

Is anyone ready to test it?

I haven't updated the release notes yet. I'll be working on that next. I have some other things going on too, so I'll try to keep it moving, but might get interrupted for a while.
Comment 8 Landry Breuil (:gaston) 2012-04-07 05:25:21 PDT
Some notes packaging-wise :

- 1.8.5 tarball was named js185-1.0.0.tar.gz
- all was in js-1.8.5/js/src, not directly js/src
- there's no mozjs187.pc.in file, similar to mosjs185.pc.in in 1.8.5 (which is still referred as-is in Makefile.in)
- build fails with gmake[1]: *** No rule to make target `RangedPtr.h', needed by `export'.  Stop. -> RangedPtr.h should be removed from EXPORTS_mozilla ? Same for RefPtr.h ? It also fails for Types.h, and i dont know how to workaround it, since that header is needed to build/included in various places.
Comment 9 Mike Hommey [:glandium] 2012-04-07 05:53:34 PDT
mfbt/ needs to be in the tarball.
Comment 10 David Mandelin [:dmandelin] 2012-04-17 17:51:27 PDT
Getting back to this. New version up at:

  http://people.mozilla.com/~dmandelin/js187-1.0.0.tar.gz

changes:

 - changed name per comment 8
 - changed root dir per comment 8
 - added mozjs187.pc.in per comment 8
 - added mfbt/ per comment 9
Comment 11 Landry Breuil (:gaston) 2012-04-18 02:06:28 PDT
Builds fine here, on;y had to backport https://hg.mozilla.org/mozilla-central/rev/9cfdb612a026 to get correct endianess detection on OpenBSD.

For some reason make install fails, mv gets passsed too much arguments:

mv -f /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libjs_static.a libjs_static.a.desc /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libmozjs187-1.0.a libmozjs187-1.0.a.desc
usage: mv [-fi] source target
       mv [-fi] source ... directory

but since it's the same chunk in 1.8.5  i guess that's a local issue (dunno where that libjs_static.a.desc comes from)

Regress tests are running fine, the only failing one is jit-test/tests/sunspider/check-date-format-tofte.js but i've always seeing it failing on OpenBSD, didnt look much further into it.
Comment 12 David Mandelin [:dmandelin] 2012-04-24 11:21:15 PDT
(In reply to Landry Breuil from comment #11)
> Builds fine here, on;y had to backport
> https://hg.mozilla.org/mozilla-central/rev/9cfdb612a026 to get correct
> endianess detection on OpenBSD.

Can you give me the backported patch so I can include it in the 1.8.7 release?
Comment 13 Landry Breuil (:gaston) 2012-04-26 03:45:23 PDT
Created attachment 618606 [details] [diff] [review]
backport bug 714312

Here you are.. i had to use AC_TRY_COMPILE as MOZ_CHECK_HEADERS wasnt available yet and the available macros dont permit to specify a second include.
Comment 14 David Mandelin [:dmandelin] 2012-04-27 12:56:41 PDT
(In reply to Landry Breuil from comment #13)
> Created attachment 618606 [details] [diff] [review]
> backport bug 714312
> 
> Here you are.. i had to use AC_TRY_COMPILE as MOZ_CHECK_HEADERS wasnt
> available yet and the available macros dont permit to specify a second
> include.

Thanks. I just updated the people.mozilla.com copy with your patch.
Comment 15 Jeff Walden [:Waldo] (remove +bmo to email) 2012-04-28 11:31:46 PDT
I just copied the 1.8.5 notes to https://developer.mozilla.org/en/SpiderMonkey/1.8.7 to start the documentation process.  Right now most of the content is just a copy of 1.8.5, so it obviously needs a *lot* of work to come close to being done.  :-)
Comment 16 Jory A. Pratt 2012-06-17 17:26:04 PDT
(In reply to Landry Breuil (:gaston) from comment #11)
> Builds fine here, on;y had to backport
> https://hg.mozilla.org/mozilla-central/rev/9cfdb612a026 to get correct
> endianess detection on OpenBSD.
> 
> For some reason make install fails, mv gets passsed too much arguments:
> 
> mv -f
> /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libjs_static.a
> libjs_static.a.desc
> /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libmozjs187-1.0.
> a libmozjs187-1.0.a.desc
> usage: mv [-fi] source target
>        mv [-fi] source ... directory
> 
> but since it's the same chunk in 1.8.5  i guess that's a local issue (dunno
> where that libjs_static.a.desc comes from)
> 
> Regress tests are running fine, the only failing one is
> jit-test/tests/sunspider/check-date-format-tofte.js but i've always seeing
> it failing on OpenBSD, didnt look much further into it.

I am seeing the same failure in Gentoo. I double checked that 1.8.5 compiled and installed fine, makes no sense why it would fail using same toolchain with 1.8.7.
Comment 17 Jory A. Pratt 2012-06-17 18:20:43 PDT
mv -f /home/anarchy/spidermonkey///usr/lib/libjs_static.a libjs_static.a.desc /home/anarchy/spidermonkey///usr/lib/libmozjs187-1.0.a libmozjs187-1.0.a.desc

As we can see here, we are failing to run mv source target, this should be a loop to ensure we are meeting the correct useage of mv.
Comment 18 Jory A. Pratt 2012-06-18 10:17:17 PDT
The issues is in config/rules.mk 

ifndef LIBRARY
ifdef STATIC_LIBRARY_NAME
REAL_LIBRARY		:= $(LIB_PREFIX)$(STATIC_LIBRARY_NAME).$(LIB_SUFFIX)
# Only build actual library if it is installed in DIST/lib or SDK
ifeq (,$(SDK_LIBRARY)$(DIST_INSTALL)$(NO_EXPAND_LIBS))
LIBRARY			:= $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX)
else
LIBRARY			:= $(REAL_LIBRARY) $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX)
endif
endif # STATIC_LIBRARY_NAME
endif # LIBRARY

Do we really need to have $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX)?
Comment 19 Jory A. Pratt 2012-06-18 11:23:00 PDT
Created attachment 634119 [details] [diff] [review]
filter-out %.$(LIBS_DESC_SUFFIX)

basic patch I am using in gentoo.
Comment 20 Jory A. Pratt 2012-06-18 11:30:37 PDT
As another team member has pointed out, we will need to ensure the public headers are installed with make install due to {jsapi,jsutil,jsval}.h needing the headers.
Comment 21 Jasper St. Pierre 2012-09-15 16:27:19 PDT
Has there been any progress on this? Our users are seeing a lot of leaks in SpiderMonkey 1.8.5 that have been fixed in later versions.
Comment 22 drago01 2012-09-27 05:51:22 PDT
(In reply to Jasper St. Pierre from comment #21)
> Has there been any progress on this? Our users are seeing a lot of leaks in
> SpiderMonkey 1.8.5 that have been fixed in later versions.

Yeah good question ... looks like that we could as well base it on FX17 ESR if it takes that much time.
Comment 23 Jeff Walden [:Waldo] (remove +bmo to email) 2012-09-27 10:55:18 PDT
Yeah, I think 17 is the time for this to happen.
Comment 24 drago01 2012-11-10 08:49:53 PST
Any news / progress on this?
Comment 25 Andre Klapper 2012-11-12 17:19:57 PST
David: So will this definitely happen for 17 and have resources been assigned to this? 
Could a priority be set?

I more and more get the feeling that usage of standalone js and braodening its developer and feedback base is not interesting for Mozilla - in that case it would be only fair to communicate that.
Comment 26 David Mandelin [:dmandelin] 2012-11-13 15:36:24 PST
(In reply to Andre Klapper from comment #25)
> David: So will this definitely happen for 17 and have resources been
> assigned to this? 
> Could a priority be set?
> 
> I more and more get the feeling that usage of standalone js and braodening
> its developer and feedback base is not interesting for Mozilla - in that
> case it would be only fair to communicate that.

Fair points and questions. 

I don't have time to work on this now. I got as far as putting together a tarball that I think is about right (based entirely on Wes's prior work), which is still on my people page (http://people.mozilla.org/~dmandelin/js187-1.0.0.tar.gz). I can't see myself setting aside the time to put together great release notes like Wes has.

We are indeed these days tightly focused on building the best SpiderMonkey specifically for Firefox products. I do wonder if we can put together a lightweight process that would allow us to put out some kind of usable source release periodically. I'll post to the list.
Comment 27 Jasper St. Pierre 2012-12-08 01:09:46 PST
This tarball does not work:

/home/jstpierre/Source/gnome3/install/include/js/jsval.h:45:24: fatal error: js/Utility.h: No such file or directory

It seems that jsapi/jsval refer to an internal Utility.h header that is not installed.
Comment 28 drago01 2013-01-02 07:07:06 PST
Rico Tzschichholz has created some patches and scripts to build tarballs for both 187 (10ESR) and 188 (17ESR):
http://people.ubuntu.com/~ricotz/mozjs/
Comment 29 darkxst 2013-01-13 18:45:34 PST
I have gnome-shell/gjs running on js188(esr17 snapsnot) and it fixes most of the issues we have been having with js185/js187, such as GC deadlocks and leaks. 

Any chance of getting a release based on esr17?
Comment 30 Kieran P 2013-01-16 16:58:50 PST
Hello. My name is Kieran. I'm part of an open source RTS game called 0 A.D. (http://play0ad.com). We embed SpiderMonkey engine into the game to allow a big part of the game to be written in Javascript.

With the many optimisations and improvements to the engine over the last few months, we'd really like to take advantage of them within the game (specifically IonMonkey) to help improve the games performance.

However, this does require the source for SpiderMonkey which can be built independently from Firefox.

Has there been any progress on creating an archive of the latest SpiderMonkey engine found in Firefox 18?
Comment 31 drago01 2013-02-10 09:07:56 PST
(In reply to darkxst from comment #29)
> I have gnome-shell/gjs running on js188(esr17 snapsnot) and it fixes most of
> the issues we have been having with js185/js187, such as GC deadlocks and
> leaks. 
> 
> Any chance of getting a release based on esr17?

Any chance to get this release out at all? The bug has been filed almost a year ago.
Comment 32 Sean Stangl [:sstangl] 2013-02-11 14:05:10 PST
(In reply to drago01 from comment #31)
> Any chance to get this release out at all? The bug has been filed almost a
> year ago.

Yes. There will be a js-1.8.8 release based on esr17 asap.

(In reply to Kieran P from comment #30)
> Has there been any progress on creating an archive of the latest
> SpiderMonkey engine found in Firefox 18?

We'll focus on an esr17 (pre-IonMonkey) release first. Although esr17 doesn't include IonMonkey, it does have JaegerMonkey with TypeInference, which should still be a huge speedup over 1.8.5.

If we track JS source releases to ESR releases, the first JS release that would include IonMonkey would be based off esr24 around November 2013.
Comment 33 Sean Stangl [:sstangl] 2013-02-11 18:03:58 PST
I created a public repository to work on JS packaging so that the process is more visible, and so that it's easier for embedders to assist in the process (or even just track it):

https://github.com/sstangl/js-packaging

The scripts are pulled from http://people.ubuntu.com/~ricotz/mozjs/ via Comment 28 with some fixes and selective rebased changesets from Bug 839727.

Current items of action include a broken 'make install' and lack of NSPR for --enable-threadsafe.

We will also need to resolve naming, because this release will not be API-compatible with 1.8.5, so calling it 1.8.8 is improper. Perhaps "1.9.0", with "/usr/include/js1.9" ala Python to permit multiple incompatible versions to coexist on a single distribution?
Comment 34 Jeff Walden [:Waldo] (remove +bmo to email) 2013-02-11 18:19:17 PST
The naming thing should be handled by bug 812265, no?  We'd just name it js17, js24, etc. with include files in /usr/include/js17/ and so on.  Maybe with minor and patchlevel components in it, too, although I'm not sure -- presumably we want 17.0.3 or whatever to be compatible with 17.0.0, but you never know what a security bug might require.  So I could see us doing patchlevel releases concurrent with ESR security/stability point releases at some point.  (Although I don't think we should set that as a hard requirement now -- we should release, then we should regroup and see about making that next step then.)
Comment 35 darkxst 2013-02-11 18:59:20 PST
yes, we should go with the patches in bug 812265, rather than the old libname patch. I have tested those and they work well, there is just a couple of minor fixes required. I will upload a fixed patch based of esr17 a bit later.
Comment 36 darkxst 2013-02-11 22:29:26 PST
This is the patchset I have been testing based off the versioning patches in bug 812265. It also contains most of the patches linked from bug 837921 (it does not however have the 'symbol conflicts' patch or 'make source package' patch).

https://github.com/darkxst/js17/commits/mozjs17-rebase

package naming is 'mozjs-17.0' and includes '/usr/include/mozjs-17.0'

This should not have have any issues with broken install, and I havent seen any nspr issues, but havent specifically looked. Also I have been building with "--enable-threadsafe --with-system-nspr"

If we end up doing point release of the esr17 series we can use the patch version in the soname suffix to handle that. (windows might need to include patch level in library name though)
Comment 37 Sean Stangl [:sstangl] 2013-02-14 15:16:43 PST
Status update for anyone watching: mostly thanks to darkxst, the js-packaging repository from Comment 33 creates a tarball that builds on linux and installs properly. The tarball creator bears a number of patches with tracking information in "package.sh".

I have put up the most recent tarball here, for early comments:
http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.1.tar.gz

The following items of work remain:
- Bug 835551 needs landing on esr17
- Bug 831552 needs landing on esr17
- Bug 812265 needs cleanup (working patch series already in js-packaging repo) and review, with possible splinter bugs.
- A leftover timestamp is installed in $(libdir)/pkgconfig/.mkdir.done.

Those are all the items on the radar at the moment. Testing on Windows and OSX would be especially appreciated.
Comment 38 Sean Stangl [:sstangl] 2013-02-20 16:32:58 PST
Status update: all known issues are resolved, and darkxst's patches are awaiting final review after some iteration. Judging by the length of time required to get approval for esr17, it looks like we'll be carrying a number of patches outside of the main repo, but that isn't a barrier to shipping. Builds and installs fine on OSX.

Latest version (built from https://github.com/sstangl/js-packaging):
http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.2.tar.gz

Once glandium approves the remaining patches, we can post a release candidate. Release won't block on notes.
Comment 39 Fabio 2013-02-21 02:12:11 PST
Maybe someone should update the web page:
https://developer.mozilla.org/en-US/docs/SpiderMonkey
with info on this upcoming release, and remove old pages:
https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.7
https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8
Comment 40 Sean Stangl [:sstangl] 2013-02-21 02:23:26 PST
(In reply to Fabio from comment #39)
> Maybe someone should update...

Yes, it's on the radar.
Comment 41 Jasper St. Pierre 2013-02-21 06:31:37 PST
Release notes aren't priority. I'd like to get the tarball out first.
Comment 42 Landry Breuil (:gaston) 2013-02-24 10:29:39 PST
(In reply to Sean Stangl from comment #38)
> Status update: all known issues are resolved, and darkxst's patches are
> awaiting final review after some iteration. Judging by the length of time
> required to get approval for esr17, it looks like we'll be carrying a number
> of patches outside of the main repo, but that isn't a barrier to shipping.
> Builds and installs fine on OSX.
> 
> Latest version (built from https://github.com/sstangl/js-packaging):
> http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.2.tar.gz

Fwiw i've tried that tarball on OpenBSD, all regress tests pass fine and i'm really happy with the changes made to packaging/versionning of include dir/binaries.. less local patches!

- one for Makefile.in to disable yarr jit on sparc64 (which is broken anyway, but if it builds it allows some depending pkgs to build)

-ifneq (,$(filter arm% sparc %86 x86_64 mips%,$(TARGET_CPU)))
+ifneq (,$(filter arm% sparc* %86 x86_64 mips%,$(TARGET_CPU)))

- one for configure.in setting our SO_VERSION from env (need to file it to get that commited, its a followup from #648721)

-    DLL_SUFFIX=".so.1.0"
+    DLL_SUFFIX=".so.${SO_VERSION}"

- http://hg.mozilla.org/tracemonkey/rev/68203913d04c backported to esr17 for sparc64, i realized bug #618485 was only commited to tracemonkey repo, and didnt made it to m-c or esr17. Will file that one too.


Only one nit : 17.0 or mozjs17 is really confusing, given that we come from 1.8.5.. it almost looks that we downgrade the version. For 1.8.5 it matched the version of the JavaScript Language..
Comment 43 darkxst 2013-02-26 20:09:27 PST
(In reply to Landry Breuil (:gaston) from comment #42)
> 
> Only one nit : 17.0 or mozjs17 is really confusing, given that we come from
> 1.8.5.. it almost looks that we downgrade the version. For 1.8.5 it matched
> the version of the JavaScript Language..

Maybe it made sense back then, but now if we continue to use the same versioning scheme, any version numbers are just going to be arbitrary numbers. Right now the major changes are in the C API and not so much the javascript version (which has moved to the ES standards as far as I can tell.), so really it makes more sense to version the library after Firefox version than the Javascript version.
Comment 44 Sean Stangl [:sstangl] 2013-02-27 14:36:08 PST
I am pleased to finally announce a release candidate for the standalone JS 17 release:

http://people.mozilla.org/~sstangl/mozjs17.0.0.rc0.tar.gz

Differences between the previous version from Comment 38 and the release candidate include the reviewed versions of darkxst's patches in Bug 812265 and the OpenBSD-specific changes from Comment 42.

Release notes were also given a placeholder on MDN, currently in template form with no useful information:

https://developer.mozilla.org/en-US/docs/SpiderMonkey/17

The plan is to wait roughly a week to gather feedback, with a final release planned for Thursday, March 7th if feedback is positive. I will also announce the release candidate on mozilla.dev.tech.js-engine: please give feedback either there or in this bug.
Comment 45 darkxst 2013-02-27 15:50:39 PST
(In reply to Sean Stangl from comment #44)
> 
> Release notes were also given a placeholder on MDN, currently in template
> form with no useful information:
> 
> https://developer.mozilla.org/en-US/docs/SpiderMonkey/17

Thats not entirely true, much of that information is very relevant to spidermonkey 17. 

In particular, typedef changes, deleted API and changed API sections. Cover most of the changes (atleast the ones I hit, in porting Gjs) in migrating from esr10 (the unreleased 1.8.7 tarball) -> 17
Comment 46 Sean Stangl [:sstangl] 2013-02-27 15:55:19 PST
(In reply to darkxst from comment #45)
> (In reply to Sean Stangl from comment #44)
> Thats not entirely true, much of that information is very relevant to
> spidermonkey 17. 

The page is a blind import of the old 1.8.8 page, and I haven't checked the relevant sections for accuracy. I hope to update/check the page before final release, but it's a good sign that it was useful for Gjs porting.
Comment 47 Sean Stangl [:sstangl] 2013-03-04 17:27:03 PST
RC1: http://people.mozilla.org/~sstangl/mozjs17.0.0.rc1.tar.gz

Fixes two classes of clang warnings, and carries fewer patches as Bug 838915 and Bug 831552 were merged onto upstream ESR17.
Comment 48 Landry Breuil (:gaston) 2013-03-08 08:16:19 PST
Still works fine on openbsd, i have two minor nits :

- i was wrong in comment 42, yarr jit doesnt work on sparc64 and i got the logic reversed (at some point it was the list of archs to exclude, now it's the list of archs where yarr is available) - so please just put 'sparc' in the list of archs, not 'sparc*'

- the construct you use for DLL_SUFFIX doesnt work, here with SO_VERSION set in the env it still uses 1.0. Can you use such construct as seen in m-c/configure.in ? See https://bugzilla.mozilla.org/show_bug.cgi?id=648721 for the background.

2307     if test "$SO_VERSION"; then
2308         DLL_SUFFIX=".so.$SO_VERSION"
2309     else
2310         DLL_SUFFIX=".so.1.0"
2311     fi

Here it does weird stuff such as
./js/src/config/autoconf.mk:DLL_SUFFIX = .so.$(if $(SO_VERSION),$(SO_VERSION),1.0)
./js/src/config/expandlibs_config.py:DLL_SUFFIX = normalize_suffix(".so.$(if $(SO_VERSION),$(SO_VERSION),1.0)")
./js/src/config.log:configure:14534: cc -shared -fPIC -pthread  -o libconftest.so.$(if $(SO_VERSION),$(SO_VERSION),1.0) -Wl
./js/src/config.log:cc: $(SO_VERSION),$(SO_VERSION),1.0): No such file or directory
./js/src/js-confdefs.h:#define MOZ_DLL_SUFFIX ".so.$(if $(SO_VERSION),$(SO_VERSION),1.0)"

Tested on amd64, will test it on other exotic archs i have around. spidermonkey currently builds on amd64/ppc/i386/alpha/mips64{,el}/sparc64/hppa, i'd like to get the same coverage..it only badly fails at runtime on mips64/sparc64 & hppa.
Comment 49 darkxst 2013-03-10 13:33:13 PDT
--- Comment #9 from Colin Walters <walters@verbum.org> 2013-03-10 20:06:54 UTC ---
One thing we need to get fixed upstream is to honor --disable-static.

-rwxr-xr-x. 1 walters walters 248M Mar 10 12:53
/src/build/jhbuild/lib64/libmozjs-17.0.a

No one should be linking the static library, and 248M is enormous!  We don't
want downstreams to be redistributing that.
Comment 50 Sean Stangl [:sstangl] 2013-03-10 15:36:38 PDT
(In reply to darkxst from comment #49)
> No one should be linking the static library, and 248M is enormous!  We don't
> want downstreams to be redistributing that.

Running "strip" drastically decreases filesizes of the static and dynamic libraries.
Comment 51 William Wang 2013-03-14 18:49:54 PDT
I think maybe spidermonkey need more activity.
because I compile js 1.8.5 under window mingw ,can't find help to solve error.
I have to turn to V8 Javascript .

spidermonkey engine situation need change.
Comment 52 Sean Stangl [:sstangl] 2013-03-15 13:21:43 PDT
(In reply to Landry Breuil (:gaston) from comment #48)
> - the construct you use for DLL_SUFFIX doesnt work, here with SO_VERSION set
> in the env it still uses 1.0. Can you use such construct as seen in
> m-c/configure.in ? See https://bugzilla.mozilla.org/show_bug.cgi?id=648721
> for the background.
> 
> 2307     if test "$SO_VERSION"; then
> 2308         DLL_SUFFIX=".so.$SO_VERSION"
> 2309     else
> 2310         DLL_SUFFIX=".so.1.0"
> 2311     fi
> 
> Here it does weird stuff such as
> ./js/src/config/autoconf.mk:DLL_SUFFIX = .so.$(if
> $(SO_VERSION),$(SO_VERSION),1.0)
> ./js/src/config/expandlibs_config.py:DLL_SUFFIX = normalize_suffix(".so.$(if
> $(SO_VERSION),$(SO_VERSION),1.0)")
> ./js/src/config.log:configure:14534: cc -shared -fPIC -pthread  -o
> libconftest.so.$(if $(SO_VERSION),$(SO_VERSION),1.0) -Wl
> ./js/src/config.log:cc: $(SO_VERSION),$(SO_VERSION),1.0): No such file or
> directory
> ./js/src/js-confdefs.h:#define MOZ_DLL_SUFFIX ".so.$(if
> $(SO_VERSION),$(SO_VERSION),1.0)"
> 
> Tested on amd64, will test it on other exotic archs i have around.
> spidermonkey currently builds on
> amd64/ppc/i386/alpha/mips64{,el}/sparc64/hppa, i'd like to get the same
> coverage..it only badly fails at runtime on mips64/sparc64 & hppa.

I'm not sure what change is required here. It looks like the relevant code on esr17 is the same as on m-c. Would you be able to provide a patch?

Once this last issue is sorted, I'll make the final release.
Comment 53 Landry Breuil (:gaston) 2013-03-16 01:37:51 PDT
Created attachment 725732 [details] [diff] [review]
If available, use SO_VERSION from configure env to set DLL_SUFFIX

Here's what i have in my wip port - same as what's in m-c.
Comment 54 Sean Stangl [:sstangl] 2013-03-25 13:48:01 PDT
Final source release (promoted RC2):

http://ftp.mozilla.org/pub/mozilla.org/js/mozjs17.0.0.tar.gz

Thanks to everyone involved in finally bringing this release to fruition, especially darkxst, glandium, Ted, Waldo, and dmandelin. I'll make a post to the js-engine mailing list shortly, and perhaps put out a post on the JS engine site.

The next JS major release will be SpiderMonkey 24, around November of this year, tracking the Firefox ESR schedule.
Comment 55 Jeff Walden [:Waldo] (remove +bmo to email) 2013-05-14 15:00:22 PDT
*** Bug 790257 has been marked as a duplicate of this bug. ***
Comment 56 Fabio 2013-06-01 00:46:05 PDT
When do you plan to start working on mozjs 24? After the official FF release or do you plan to release alpha versions early, maybe synced with FF test release?
Comment 57 Sean Stangl [:sstangl] 2013-06-04 10:30:31 PDT
(In reply to Fabio from comment #56)
> When do you plan to start working on mozjs 24? After the official FF release
> or do you plan to release alpha versions early, maybe synced with FF test
> release?

When 24 moves from Nightly to Aurora (around June 24), I'll work on putting out a version. This obviously cannot be considered a release candidate, but the API should be stable between Aurora and release, and I'll track any major changes.

Release candidates can start appearing after 24 is out of beta, around late September.
Comment 58 Fabio 2013-09-22 00:20:09 PDT
(In reply to Sean Stangl [:sstangl] from comment #57)
> When 24 moves from Nightly to Aurora (around June 24), I'll work on putting
> out a version. This obviously cannot be considered a release candidate, but
> the API should be stable between Aurora and release, and I'll track any
> major changes.
> 
> Release candidates can start appearing after 24 is out of beta, around late
> September.

24 was released, is there a new bug for tracking mozjs 24?
Comment 59 darkxst 2013-09-22 03:00:41 PDT
There is now!

https://bugzilla.mozilla.org/show_bug.cgi?id=919277
Comment 60 Florian Scholz [:fscholz] (MDN) 2015-01-06 09:54:30 PST
mozjs 17 is out for a long time, closing the doc request. Some notes are at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases/17

Note You need to log in before you can comment on or make changes to this bug.