GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — gh-145177: Bump emscripten to 5.0.4 by hoodmane · Pull Request #151421 · python/cpython

Conversation

@hoodmane

@hoodmane hoodmane commented Jun 12, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@hoodmane
hoodmane requested review from emmatyping and freakboy3742 as code owners June 12, 2026 23:26
@hoodmane hoodmane added skip news needs backport to 3.15 bugs and security fixes labels Jun 12, 2026
@bedevere-app bedevere-app Bot added the awaiting review label Jun 12, 2026
@bedevere-app bedevere-app Bot mentioned this pull request Jun 12, 2026
Emscripten buildbot: Support multiple Emscripten versions #145177
Closed
@hoodmane

hoodmane commented Jun 13, 2026

Copy link
Copy Markdown
Contributor Author

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane
hoodmane marked this pull request as draft June 13, 2026 15:14
@bedevere-app bedevere-app Bot removed the awaiting review label Jun 13, 2026
@hoodmane
hoodmane force-pushed the emscripten-6.0.0 branch 2 times, most recently from e0e9b3d to 6f1b85c Compare June 14, 2026 17:18
@hoodmane hoodmane changed the title gh-145177: Bump emscripten to 6.0.0 gh-145177: Bump emscripten to 5.0.4 Jun 14, 2026
@hoodmane
hoodmane marked this pull request as ready for review June 14, 2026 17:19
@bedevere-app bedevere-app Bot added the awaiting review label Jun 14, 2026
freakboy3742
freakboy3742 requested changes Jun 15, 2026
View reviewed changes

@freakboy3742 freakboy3742 left a comment

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@bedevere-app bedevere-app Bot added awaiting changes and removed awaiting review labels Jun 15, 2026
@bedevere-app

bedevere-app Bot commented Jun 15, 2026

Copy link
Copy Markdown

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.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@ryanking13

ryanking13 commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane
pythongh-145177: Bump emscripten to 5.0.4
751d80f 
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 leave updating past that to a followup.
@hoodmane
hoodmane force-pushed the emscripten-6.0.0 branch from 6f1b85c to 751d80f Compare June 15, 2026 22:17
@freakboy3742

freakboy3742 commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

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?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor Author

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.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@freakboy3742

freakboy3742 commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

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 reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hoodmane

hoodmane commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

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.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@hugovk

hugovk commented Jun 17, 2026

Copy link
Copy Markdown
Member

Rather than ad-hoc decisions for 3.15 and again for 3.16 and beyond, is it worth formalising a support policy? Perhaps as an update to PEP 776.

Compare what Brett did with PEP 816 for WASI support, which was a short discussion.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@freakboy3742

freakboy3742 commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Rather than ad-hoc decisions for 3.15 and again for 3.16 and beyond, is it worth formalising a support policy? Perhaps as an update to PEP 776.

I agree a formal policy would be preferable; following the analog of PEP 816 seems like a reasonable starting point.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@freakboy3742 freakboy3742 mentioned this pull request Jun 18, 2026
gh-145177: Bump Emscripten to 6.0.0 #151611
Merged
@hoodmane hoodmane closed this Jun 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@freakboy3742 freakboy3742 freakboy3742 requested changes
@emmatyping emmatyping Awaiting requested review from emmatyping emmatyping is a code owner

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

awaiting changes needs backport to 3.15 bugs and security fixes skip news

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

4 participants

@hoodmane @ryanking13 @freakboy3742 @hugovk
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.