update to new mozjs-17 library

[Tim Lunn]

The release of a new mozjs library should be happening later this month, which will be based of the Firefox esr17 engine. Atleast with respect to gnome-shell the new release fixes lots of leaks and Garbabe Collector (GC) deadlocks. Since this would be good to get this update into raring, creating this as a tracking bug.

Gjs 1.35 has been ported (which should land upstream before gnome freeze mid Feb) and I have tested this against both gnome-shell 3.6 and 3.7, there are significant improvements in memory usage, and I have not seen a single GC deadlock.

Currently none of the other rdepends have been ported as far as I know, and its probably not realistic to get all of them ported before the Ubuntu freeze. There are quite a lot of trivial API changes between mozjs185 and 188, although most are picked up by compiler errors or seg faults. A large portion of the work could be done by some compatibility defines and some sed magic, however the end results is quite a large diff, so probably not something that would want to carry as a distro patch. As such, atleast for the short-term would probably need to have a transition period with both versions available.

Reverse Depends:
  libgjs0c
  gnome-shell (will just require rebuild)
  oolite
  gxine
  gnome-shell
  dehydra
  couchdb-bin
  cinnamon (will just require rebuild)
  0ad (I believe upstream want to go straight to FF18)

One last thing is that the soname format will probably change to libmozjs-17.0.so (i.e. Firefox versioning).

[Drago01 (drago01)]

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?

[Dmandelin (dmandelin)]

(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?

[Drago01 (drago01)]

(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.

[Dmandelin (dmandelin)]

OK, it might take a while to spin this up, but it's on my list.

[Drago01 (drago01)]

(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!

[Dmandelin (dmandelin)]

Getting ready to work on this. First tiny step: updating title to match what was used last time around in bug 628723.

[Dmandelin (dmandelin)]

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

[Dmandelin (dmandelin)]

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.

[Landry-openbsd (landry-openbsd)]

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.

[Mh+mozilla (mh+mozilla)]

mfbt/ needs to be in the tarball.

[Dmandelin (dmandelin)]

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

[Landry-openbsd (landry-openbsd)]

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.

[Dmandelin (dmandelin)]

(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?

[Landry-openbsd (landry-openbsd)]

Created attachment 618606
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.

[Dmandelin (dmandelin)]

(In reply to Landry Breuil from comment #13)
> Created attachment 618606
> 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.

[Jwalden+bmo (jwalden+bmo)]

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. :-)

[Anarchy (anarchy)]

(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.

[Anarchy (anarchy)]

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.

[Anarchy (anarchy)]

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)?

[Anarchy (anarchy)]

Created attachment 634119
filter-out %.$(LIBS_DESC_SUFFIX)

basic patch I am using in gentoo.

[Anarchy (anarchy)]

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.

[Jasper St. Pierre (jstpierre)]

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.

[Drago01 (drago01)]

(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.

[Jwalden+bmo (jwalden+bmo)]

Yeah, I think 17 is the time for this to happen.

[Drago01 (drago01)]

Any news / progress on this?

[Andre Klapper (a9016009)]

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.

[Dmandelin (dmandelin)]

(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.

[Jasper St. Pierre (jstpierre)]

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.

[Drago01 (drago01)]

Rico Tzschichholz has created some patches and scripts to build tarballs for both 187 (10ESR) and 188 (17ESR):
http://people.ubuntu.com/~ricotz/mozjs/

[Darkxst-k (darkxst-k)]

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?

[Kieran776 (kieran776)]

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?

[Jwalden+bmo (jwalden+bmo)]

I never remember the full set of these. It also *really* doesn't help some of them are in Core::Build Config, so they never show up in my (quick)searches for JS bugs until I remember my mistake.

I wish we had SpiderMonkey as a product, with subcomponents for the JITs, Build Config, interpreter, blah blah blah.

Anyone feel free to add other bugs to this list. I'm just dumping the ones I have "stored" in tabs right now, which are doubtless incomplete. :-)

[Drago01 (drago01)]

(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.

[Sstangl (sstangl)]

(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.

[Sstangl (sstangl)]

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?

[Jwalden+bmo (jwalden+bmo)]

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.)

[Darkxst-k (darkxst-k)]

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.

[Darkxst-k (darkxst-k)]

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)

[Sstangl (sstangl)]

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.

[Sstangl (sstangl)]

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.

[Oibaf (oibaf)]

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

[Sstangl (sstangl)]

(In reply to Fabio from comment #39)
> Maybe someone should update...

Yes, it's on the radar.

[Jasper St. Pierre (jstpierre)]

Release notes aren't priority. I'd like to get the tarball out first.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Landry-openbsd (landry-openbsd)]

(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..

[Darkxst-k (darkxst-k)]

(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.

[Sstangl (sstangl)]

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.

[Darkxst-k (darkxst-k)]

(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

[Sstangl (sstangl)]

(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.

[Tim Lunn (darkxst)]

Release Candidate has been released
https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c44

[Sstangl (sstangl)]

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.

[Oibaf (oibaf)]

Link to proper upstream bug.

[Rico Tzschichholz (ricotz)]

A package is available here:
https://launchpad.net/~ricotz/+archive/testing/+packages?field.name_filter=mozjs&field.status_filter=published&field.series_filter=raring

[Landry-openbsd (landry-openbsd)]

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.

[Darkxst-k (darkxst-k)]

--- Comment #9 from Colin Walters <email address hidden> 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.

[Sstangl (sstangl)]

(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.

[Sunose (sunose)]

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.

[Sstangl (sstangl)]

(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.

[Landry-openbsd (landry-openbsd)]

Created attachment 725732
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.

[Sstangl (sstangl)]

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.

[Jwalden+bmo (jwalden+bmo)]

*** Bug 790257 has been marked as a duplicate of this bug. ***

[Jeremy Bícha (jbicha)]

Tim or Rico, could you please attach or point to a package that is ready for sponsoring into saucy and then subscribe ubuntu-sponsors? The one in the GNOME3 PPA or the Ricotz Testing PPA is missing a complete changelog. Thanks!

[Tim Lunn (darkxst)]

Here is a debdiff that adds a complete changelog, it is taken against the mozjs17 package on the gnome3 ppa.

[Jeremy Bícha (jbicha)]

Thanks Tim & Rico. Uploaded to the saucy new queue.

[Oibaf (oibaf)]

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?

[Sstangl (sstangl)]

(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.

[Oibaf (oibaf)]

(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?

[Darkxst-k (darkxst-k)]

There is now!

https://bugzilla.mozilla.org/show_bug.cgi?id=919277

[Fscholz (fscholz)]

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