Update SpiderMonkey to ESR128.0

[sagudev]

Thankfully we were more prepared now: #462

It compiles! Streams patch was successfully ported.

Biggest changes:

• For intl support we need to compile icu_capi from our cargo.toml (similar to what we do with encoding_c)
• There were some changes around zlib (when it's allowed to use sys zlib) so I ripped all zlib out to always use zlib provided by libz-sys crate
• Support for offthread compilation is removed, so we will need to roll our own (before it was done as a task on JS Helpers thread poll), this is planned to be done as a follow up according to plan outlined here: Update SpiderMonkey to ESR128.0 #474 (comment)
• min mac sdk is now on 14.2 (needs CI fixes: xcode 15.2, will become default [macOS] Default Xcode on macOS 13 Ventura will be set to Xcode 15.2 on July, 15 actions/runner-images#10120)
• min NDK is 26
• we now build proper static lib in windows, reducing artifact size: 1a084f0

Companion PR in servo: servo/servo#32769

[sagudev]

Another problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1887728, we need macos sdk 14.4, but this requires Xcode 15.4, that is not available on macos 13 (so we got no x86 runners). I think it would be possible to patch it for this ESR cycle.

[sagudev]

@wusyong Any idea why this is happening: https://github.com/servo/mozjs/actions/runs/9902233667/job/27356251099#step:4:826, I manually checked and there is s_truncf.obj in zip?

[wusyong]

@wusyong Any idea why this is happening: https://github.com/servo/mozjs/actions/runs/9902233667/job/27356251099#step:4:826, I manually checked and there is s_truncf.obj in zip?

Hmm, it's weird because I checked out to your branch and used that artifact and it seems fine. I'll look into it.

[wusyong]

Okay I got the error. It seems the hash isn't correct?

Take current build for example:
note: lld-link: error: D:\a\mozjs\mozjs\target\debug\build\mozjs_sys-b0f045240069a423\out\build/js/src/build\js_static.lib: could not get the buffer for a child of the archive: 'D:/a/mozjs/mozjs/target/x86_64-pc-windows-msvc/debug/build/mozjs_sys-c2a3d4c65cace61a/out/build/modules/fdlibm/src/s_truncf.obj': no such file or directory

The build is mozjs_sys-b0f045240069a423 but the linker somehow search for mozjs_sys-c2a3d4c65cace61a

Edit: And on my side, it also tried to look for this hash c2a3d4c65cace61a somehow.
Edit2: More specifically, it's always D:/a/mozjs/mozjs/target/x86_64-pc-windows-msvc/debug/build/mozjs_sys-c2a3d4c65cace61a/out/build/modules/fdlibm/src/s_truncf.obj'

[wusyong]

I guess we should take this chance to finally build static library on msvc without linking any object files.

[sagudev]

The build is mozjs_sys-b0f045240069a423 but the linker somehow search for mozjs_sys-c2a3d4c65cace61a

something must be causing hash change.

I guess we should take this chance to finally build static library on msvc without linking any object files.

Ideally yes.

[sagudev]

Doing ar r js/src/build/js_static.lib modules/fdlibm/src/*.obj should be enough I think.

[wusyong]

Doing ar r js/src/build/js_static.lib modules/fdlibm/src/*.obj should be enough I think.

I'm wondering if there's a flag that can enable it. Because other platforms' static libraries just need the .a file.

[sagudev]

Doing ar r js/src/build/js_static.lib modules/fdlibm/src/*.obj should be enough I think.

I'm wondering if there's a flag that can enable it. Because other platforms' static libraries just need the .a file.

I think something is wrong with build sys (in SM), that doesn't make static really static on windows.

[sagudev]

For offthread compilation I plan to make compileToStencil function that will do everything the threads needs to do, then implement CompileToStencilOffThread in mozjs (now with rust/safe api that will still resemble ESR115 API), that will create new thread on each invocation (the thread will run compileToStencil).

So servo will be migrated to this CompileToStencilOffThread for now (in the future we can use compileToStencil to implement thread pooled version of CompileToStencilOffThread in servo).

Not sure if this will be done as part of SM bump effort or as a follow up (depending on the amount of changes needed).

[sagudev]

I will land this myself, after companion PR get's reviewed.

[jdm]

Fantastic work figuring out all these new API changes and build issues!