Upgrade Emscripten to 5.0.6

[krauthaufen]

Emscripten 5.0.6 / LLVM 23 toolchain upgrade — current state

Research snapshot compiled 2026-06-18 for the WASM/Browser toolchain bump.
Sources: runtime PR #129299, tracking issue
#113786, the VMR source-manifest.json,
this repo on branch emsdk-upgrade, and live Maestro/BAR data via authenticated
darc (build IDs, channels, last-applied builds verified).

1. Goal

Bring the new WebAssembly toolchain (Emscripten 5.0.6, LLVM 23 + transports)
onto dotnet11/main only. Older versions (.NET 10 / 9 / 8, release branches and
their VMR equivalents) must keep the old toolchain (Emscripten 3.1.56, LLVM 19).

2. Toolchain components: old → new

Component	Old	New	Repo	In VMR?
Emscripten SDK	emsdk 3.1.56	emsdk 5.0.6	https://github.com/dotnet/emsdk	✅ yes
LLVM	19.x	23.1.0	https://github.com/dotnet/llvm-project	❌ no
Binaryen	3.1.56-era	5.0.6 (54f9f7af)	https://github.com/dotnet/binaryen	❌ no
Emscripten core	3.1.56	5.0.6 (6ea9c28c)	https://github.com/dotnet/emscripten	❌ no
Node	v18.x	v24.7.0 ✅ accepted (plan had v22.16.0)	https://github.com/dotnet/node	❌ no
CPython	3.11	3.13.3	https://github.com/dotnet/cpython	❌ no
ICU	LLVM19/3.1.56	rebuild for LLVM23/5.0.6	https://github.com/dotnet/icu	❌ no

3. Topology — VMR vs. non-VMR

VMR source-manifest.json: only emsdk is a VMR component (commitSha ab6c174e…).
Not in VMR: llvm-project, binaryen, emscripten, node, cpython, icu.

Reach into runtime/VMR (verified subscriptions):

• LLVM .NET 11 → dotnet/dotnet main (VMR), + binaryen/node/wasi-sdk dotnet/main.
  ⚠️ Not WASM-specific — drives Mono LLVM AOT on all platforms + LLVM JIT tools
  (cross-platform blast radius; Mono AOT regressions
  MonoAOT: LLVM 23 regressions in Half NaN handling #129507,
  MonoAOT: LLVM 23 regressions in FullAOT JIT test outcomes #129508,
  MonoInterp/Minijit win-x64: COM interop (SafeArray/Variant/struct reverse-pinvoke) test failures #129581,
  [wasm] Wasm.Build.Tests EventPipeDiagnosticsTests CPU-sampling tests fail after emsdk 5.0.6 / LLVM 23 legacy-EH change #129584).
• ICU .NET 11 → dotnet/runtime main directly.
• emsdk .NET 11 → dotnet/dotnet main (VMR) + dotnet/performance main.
• node/cpython/binaryen/emscripten .NET 11 → emsdk main (cpython/node also → VMR).

4. Verified channel model — per-branch → per-.NET-version

dotnet/main→**.NET 11**; release/10.0→.NET 10; release/9.0→.NET 9; release/8.0→.NET 8
(for every toolchain repo). The .NET 11 channel only flows into main /
VMR-main / runtime-main. .NET 10/9/8 channels flow only into the consumers'
release branches. ➡️ Containment to dotnet11/main is structural.

5. Cut-over state — VERIFIED build-level audit (2026-06-18)

All seven repos already build the new content from dotnet/main onto the .NET 11
channel. Latest .NET 11 builds:

Repo	.NET 11 build	branch	buildNumber	commit	content
llvm-project	318623	dotnet/main	20260614.2	921a6f0c	LLVM 23
binaryen	317882	dotnet/main	20260609.1	d9340929	Binaryen 5.0.6
emscripten	318637	dotnet/main	20260614.1	5a0efb2b	Emscripten 5.0.6
node	318579	dotnet/main	20260612.1	fce4570e	Node v24.7.0
cpython	318526	dotnet/main	20260612.1	5a7cb4e9	CPython 3.13.3
icu	316564	dotnet/main	20260531.1	d94093d6	still 3.1.56 (old)
emsdk	318639	main	20260614.2	c9ecee1e	emsdk 5.0.6

(emsdk main eng/Versions.props = EmscriptenVersion 5.0.6, confirmed.)

⚠️ Published vs. applied gap (the live hazard)

The new builds are on .NET 11, but consumers have only partially applied them:

Subscription	Last APPLIED build	= content	Latest on .NET 11
llvm → dotnet/dotnet main (everyWeek)	313447, branch dotnet/main-19.x, 5/6	LLVM 19	318623 = LLVM 23 (pending)
node → dotnet/dotnet main (everyWeek)	317102, dotnet/main, 6/3	Node v24.7 (applied)	318579
cpython → emsdk main (everyDay)	318526, dotnet/main	3.13.3 (applied)	318526
binaryen → emsdk main (everyDay)	317882, dotnet/main	5.0.6 (applied)	317882
emscripten → emsdk main (everyDay)	318637, dotnet/main	5.0.6 (applied)	318637
emsdk → dotnet/dotnet main (everyDay)	317682, main, 6/8 (= VMR emsdk SHA)	emsdk (applied)	318639
icu → dotnet/runtime main (everyDay)	316564, dotnet/main, 5/31	3.1.56 (old)	316564

Interpretation:

• node/cpython/binaryen/emscripten/emsdk new builds are already flowing into
  emsdk main and the VMR main (= .NET 11). The VMR's emsdk is the bumped line.
• LLVM is the laggard in the FLOW: the VMR last applied LLVM 19 (from
  dotnet/main-19.x, 5/6). But dotnet/main-19.x (LLVM 19) AND dotnet/main
  (LLVM 23) are BOTH publishing to .NET 11. The everyWeek llvm→VMR subscription
  will pull the latest .NET 11 build = LLVM 23 (318623) on its next run —
  automatically, regardless of Upgrade Emscripten to 5.0.6 & LLVM to 23 #129299.
• icu is not bumped (dotnet/main still 3.1.56); runtime main ICU = old.
• Runtime source is gated: dotnet/runtime main EmsdkVersion = 3.1.56 and the
  mono mini-llvm.c LLVM-23 patches are a hardcoded source property / source code
  updated only by PR Upgrade Emscripten to 5.0.6 & LLVM to 23 #129299, independent of
  the package flow.

6. The real risk picture

1. No leak to older versions — .NET 11 only feeds main/VMR-main. .NET 10/9/8
   use independent release branches. The new toolchain reaches older versions only if
   a bump is merged to a release/* branch or a build is assigned to a .NET 10/9/8
   channel. Neither has happened.
2. 🔴 LLVM 23 is about to auto-flow into the VMR .NET 11 (everyWeek) BEFORE the
   runtime source changes (Upgrade Emscripten to 5.0.6 & LLVM to 23 #129299) land —
   VMR/runtime main could fail to build (needs mini-llvm.c LLVM-23 patches +
   EmsdkVersion=5.0.6). This is a .NET 11 self-consistency/sequencing hazard, not a
   cross-version leak.
3. Dual LLVM on .NET 11 — dotnet/main-19.x (LLVM 19) should be removed from
   .NET 11 so the channel carries only LLVM 23; otherwise consumers can flip-flop.
4. icu lag — icu dotnet/main still 3.1.56; the ICU side needs
   [wasm] Bump ICU transport for Emsdk 5.0.6 / LLVM 23 icu#764.

7. PR / branch status

Repo	PR	State
llvm-project	dotnet/llvm-project#746	merged; dotnet/main = LLVM 23; on .NET 11 (not yet applied to VMR)
binaryen	dotnet/binaryen#355	merged; on .NET 11; applied to emsdk main
emscripten	dotnet/emscripten#240	merged; on .NET 11; applied to emsdk main
node	dotnet/node#335	merged (v18→v24.7.0, accepted); on .NET 11; applied to VMR
cpython	dotnet/cpython#210	merged; on .NET 11; applied to emsdk main
icu	dotnet/icu#764	PR pushed, not merged; pins staged emsdk 5.0.6 transport 11.0.0-preview.6.26314.102 + general-testing feed
emsdk	dotnet/emsdk#1712	main = emsdk 5.0.6; on .NET 11; flowing to VMR
runtime	#129299	draft; consumes staged general-testing/ci.dot.net/dev feed; source patches (LLVM23, EmsdkVersion=5.0.6) gated here. browser_mt split to #129503 (lands first)

8. Decisions / open items

• ✅ Node v24.7.0 accepted (already on dotnet/main and flowing).
• The general-testing / ci.dot.net/dev feed wiring in
  Upgrade Emscripten to 5.0.6 & LLVM to 23 #129299 is temporary — revert to production
  feeds before merge.
• Sequencing (see plan.md): land [browser][mono][MT] Prep for emscripten upgrade #129503 →
  land Upgrade Emscripten to 5.0.6 & LLVM to 23 #129299 (with production repins) in
  lockstep with the LLVM-23 .NET 11 flow; remove main-19.x from .NET 11; merge
  [wasm] Bump ICU transport for Emsdk 5.0.6 / LLVM 23 icu#764.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[vulkan101]

I'd like to look at contributing to this, as I also have a need for updated emscripten version (bugs around memory growth with MEMORY64 option are resolved in 4.0.5).
From "Upgrading Emscripten" in the "Build WebAssembly" readme, bumping Emscripten version involves these steps:

• update https://github.com/dotnet/runtime/blob/main/src/mono/wasm/emscripten-version.txt
• bump emscripten versions in docker images in https://github.com/dotnet/dotnet-buildtools-prereqs-docker
• bump emscripten in https://github.com/dotnet/emsdk
• bump docker images in https://github.com/dotnet/icu, update emscripten files in eng/patches/
• update version number in docs
• update Microsoft.NET.Runtime.Emscripten.<emscripten version>.Node.win-x64 package name, version and sha hash in https://github.com/dotnet/runtime/blob/main/eng/Version.Details.xml and in https://github.com/dotnet/runtime/blob/main/eng/Versions.props. the sha is the commit hash in https://github.com/dotnet/emsdk and the package version can be found at https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet6
• update packages in the workload manifest https://github.com/dotnet/runtime/blob/main/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.json.in

Do I need to do all the above for a local test? The "Build WebAssembly" doc is actually referenced by the "Building Mono" readme, and appears to be specific to mono. If someone could outline what I'd need to do in addition to/instead of this that would really help.

[lewing]

cc @radekdoulik @akoeplinger