gh-145177: Bump emscripten to 5.0.4

[hoodmane]

Before Emscripten 4.0.19, there was a bug in the dynamic loader that caused any
dynamic library that links libffi to fail to load. _ctypes_test.so unnecessarily
links libffi so it would fail to load and tests that needed it were skipped.

There are two test failures behind that: one involving stack overflows which
we have to skip as usual, and one that assumes that the abi for a function
that takes a single struct with two doubles is the same as the abi for a
function that takes two double arguments. This is not true in webassembly so we
skip the test.

There is another regression in Emscripten 5.0.5 which breaks a couple tests in
test_secrets and test_random, so I'm leaving updating past that to a followup.

Ideally #151423 should merge before this.

• Issue: Emscripten buildbot: Support multiple Emscripten versions #145177

[hoodmane]

Okay there are still a few other test failures to investigate here.

[freakboy3742]

This all makes sense, once (as you've noted) #151423 has landed.

The only question I have is about the backport strategy (and, I guess, the wider strategy about when the cutoff for Emscripten version bumps actually is). Should this be back ported to the 3.15 branch? The beta is the point at which binary and byte code compatibility is guaranteed for any other platform; Emscripten version compatibility would seem to be in the same boat - except that binary compatibility in practice is really determined by the PEP 783 pyemscripten tag.

However, pyemscripten_2026_0 (matching 3.14) is still listed as "in development", and pyemscripten_2027_0 (which would match 3.15) isn't listed at all, which would seem to suggest backporting this won't cause incompatibilities.

So - from Pyodide's perspective, when is the pyemscripten_X_0 tag finalised?

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[hoodmane]

pyemscripten_2026_0 is now frozen at 5.0.3 whereas the cpython 3.14 branch is on 4.0.12. I think it's a separate task we have to do to sync these up. Pep 783 being accepted clears a major blocker, and I think it'd be nice if we made a Pyodide release with Python 3.15 soon after Python 3.15 itself is released. We will have to discuss a bit more with the other Pyodide maintainers cc @ryanking13

But it would be nice if Python 3.15 can be based on Emscripten 6.0.0 or later because until version 6.0.0 Emscripten ignored the -shared flag but from now on it respects it. This should allow a simplification of our cross build system.

[ryanking13]

However, pyemscripten_2026_0 (matching 3.14) is still listed as "in development",

Ah, pyemscripten_2026_0 is now finalized as of Pyodide 314.0.0 release at June 9. I forgot to update the documentation 😓

I think it'd be nice if we made a Pyodide release with Python 3.15 soon after Python 3.15 itself is released. We will have to discuss a bit more with the other Pyodide maintainers cc @ryanking13

Yeah, agreed. Probably it would be good to discuss how we should match the Emscripten version build and tested in CPython and Pyodide repo, but maybe Pyodide should follow the version that is used in CPython CI

[hoodmane]

But based on Pyodide's communications, I don't think anyone expects the Python 3.15 pyemscripten ABI to be frozen yet.

[freakboy3742]

pyemscripten_2026_0 is now frozen at 5.0.3 whereas the cpython 3.14 branch is on 4.0.12. I think it's a separate task we have to do to sync these up. Pep 783 being accepted clears a major blocker, and I think it'd be nice if we made a Pyodide release with Python 3.15 soon after Python 3.15 itself is released. We will have to discuss a bit more with the other Pyodide maintainers cc @ryanking13

@hugovk should also be involved in that discussion, since it affects the stable branch. On my interpretation, it would be unusual, but not completely unprecedented to switch something with binary compatibility consequences once a branch is stable - I don't know if compatibility with the published pyemscripten tag would meet that bar.

But it would be nice if Python 3.15 can be based on Emscripten 6.0.0 or later because until version 6.0.0 Emscripten ignored the -shared flag but from now on it respects it. This should allow a simplification of our cross build system.

What are the blockers on moving to 6.0.0 (other than "a patch that includes it")? Based on the major version bump, I presume there is? If a 6.0.0 bump is on the horizon, should we hold off on this PR until we know if 6.0.0 will be viable?

[hoodmane]

6.0.0 is a major bump because of the change to shared libraries I mentioned. There are a couple of minor bugs involving entropy that need to be fixed on 5.0.5 but the same tests pass on 6.0.0 as on 5.0.5 so I'm quite confident it's feasible.

[hoodmane]

If you like I can make a PR on top of this for 6.0.0 and check that it's green first.

[freakboy3742]

If you like I can make a PR on top of this for 6.0.0 and check that it's green first.

We might as well try to do it in one lift rather than two if we can.

[hoodmane]

Regression in 5.0.5 is due to this commit:
emscripten-core/emscripten#26526

[hoodmane]

Okay and there's a fix here:
emscripten-core/emscripten#27122

but it turns out there is a second independent regression in Emscripten libc...

[hoodmane]

Okay seems to be that Emscripten libc started doing something slightly more sophisticated with umask than completely ignoring it. But it's maybe not 100% correct either.