Emscripten: Add druntime & Phobos support by kinke · Pull Request #5259 · ldc-developers/ldc

kinke · 2026-08-10T13:07:47Z

Based on predefined CRuntime_Musl, WASI and WASIp1.

Also add an according CI job similar to the WASI one, incl. generating an addon package.

kinke · 2026-08-10T13:33:52Z

@QuantumSegfault: This seems like a viable approach - basing Emscripten on your WASI work, after reading https://v8.dev/blog/emscripten-standalone-wasm and noting that they apparently try to use WASI APIs as much as possible, even in non-standalone-wasm mode.

To get the druntime test runners to link, I only had to avoid a single undefined _CLOCK_MONOTONIC symbol. And a single module fails its unittests (core.sync.event): https://github.com/ldc-developers/ldc/actions/runs/31392028311/job/93465932716?pr=5259

…r too]

QuantumSegfault · 2026-08-10T17:07:48Z

I'm not sure this makes sense to do like this.

Emscripten use a more vanilla Musl, without all of the differences to the headers WASI-libc made. They opted to stub out functions, rather than remove them, and otherwise use the unmodified types, constants, etc. (other than where architecture specific differences are concerned). A lot of the CRuntime_WASI blocks, particularly in Phobos, may be unnecessary.

WASI is also iffy, as that's an internal implementation detail. Emscripten also provides fuller emulation of things like threads, that we disable tests for on WASI. Also they provide their own filesystem, which isn't subject to all the quirks of WASI (e.g. the inability to have absolute symlinks; though that's largely a Wasmtime limitation).

kinke · 2026-08-10T17:57:47Z

Yeah the importc_compare test shows a number of incompatible declarations, seemingly matching your points. - I'll pursue this a bit further, trying to get it more or less green (edit: i.e., the druntime/Phobos parts tested for WASI too). Then different avenues (e.g., based on CRuntime_Musl alone instead of WASI, WASIp1 and CRuntime_WASI) can be explored as well.

I'd hope that Emscripten would eventually be based on wasi-libc...

Based on the C+ headers.

kinke · 2026-08-13T19:18:04Z

Okay, this is now based on CRuntime_Musl with a few Emscripten special-cases (instead of CRuntime_WASI earlier), but still uses WASI[p1] too (mainly to inherit the disabled parts and unitests). importc_compare is truly green; druntime still fails for a single core.sync.event unittest (depending on pthread_cond_timedwait), and Phobos just fails 2 std.datetime modules unittests, apparently just because I haven't found a way to make the node process use the /usr/share/zoneinfo host timezone files.

I'm okay with depending/building on predefined WASI, at least for the time being; supporting the few potential Posix API parts being stubbed/emulated on Emscripten and not available for WASI are IMO not of big interest. What's of interest to me is that Emscripten support is at a similar level to wasi-libc, so that wasm users can target both platforms with little to no hassle.

QuantumSegfault · 2026-08-13T19:35:17Z

I'm okay with depending/building on predefined WASI, at least for the time being; supporting the few potential Posix API parts being stubbed/emulated on Emscripten and not available for WASI are IMO not of big interest. What's of interest to me is that Emscripten support is at a similar level to wasi-libc, so that wasm users can target both platforms with little to no hassle.

Threading is a notable difference. Emscripten actually DOES support threading (over web workers; with some caveats).

https://emscripten.org/docs/porting/pthreads.html

Signals still not, other than for pthread_kill

Though I wouldn't mind holding off on the threading discussion until I figure out WASIp3 (with wasi-sdk 34 and LLVM 23 coming up; which will support cooperative threading [like Emscripten]; no preemptive threading yet though).

Other than that I think the rest of the WASI route-arounds should be fine, if not always necessary.

kinke · 2026-08-13T19:48:38Z

Though I wouldn't mind holding off on the threading discussion until I figure out WASIp3

Yeah that sounds good to me. [And note that I've just started with WASIp1, no idea if WASIp2 might be a better match for Emscripten.] - In the long run, if Emscripten is to survive, I can definitely imagine it being based on wasi-libc and its Posix emulation layer in the future. So the distinction might go away, and duplicating all current Emscripten divergences potentially not worth the effort.

The compiler has a special case wrt. TLS globals for wasm in general IIRC, emitting them as thread-global; so the compiler will probably have to be adapted for wasm threading too.

QuantumSegfault · 2026-08-13T19:55:23Z

Yeah that sounds good to me. [And note that I've just started with WASIp1, no idea if WASIp2 might be a better match for Emscripten.]

I'm fairly certain that WASIp1 is the only valid option for Emscripten.

They provide a subset of WASIp1 for the web (but not p2+ AFAICT)

https://github.com/emscripten-core/emscripten/blob/main/src/lib/libwasi.js

The compiler has a special case wrt. TLS globals for wasm in general IIRC, emitting them as thread-global; so the compiler will probably have to be adapted for wasm threading too.

Good to know.

QuantumSegfault · 2026-08-13T19:58:29Z

    enum B_NO_TRANSLATOR                 = (B_TRANSLATION_ERROR_BASE + 1);
    enum B_ILLEGAL_DATA                  = (B_TRANSLATION_ERROR_BASE + 2);
 }
-else version (CRuntime_WASI)


These errno are correct, but Emscripten provides additional ones:

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/errno.h

Yeah here I was lazy and didn't want to duplicate the existing CRuntime_WASI block, after seeing that the Emscripten headers forward the WASI codes. [And I don't really care about the extra ones; if people relied on them, their code wouldn't work with WASI.]

At least a comment wrt. Emscripten would be good though; there's some polishing left to do, hence the draft state and WIP title. :)

Yeah. Just the one thing that stuck out as probably somehow wrong, so I checked.

I'll wait for it to be undrafted before reviewing the changes more thoroughly.

kinke · 2026-08-13T20:14:23Z

-    tool = getCC(argsBuilder->args);
-  }
+  auto argsBuilder = std::make_unique<ArgsBuilder>();
+  std::string tool = getCC(argsBuilder->args);


This is e.g. also still to polish, causing the Alpine CI job failures (no integrated LLD, but external wasm-ld).

This all dates back to the very early wasm support, like the wasm-defaults .conf file - we used to only support bare-metal wasm, so no druntime and Phobos to link, and no need for a C compiler as linker driver, since there wasn't a wasm libc support either. So we used to invoke wasm-ld (unless we have an integrated LLD) with the ld CLI interface, for all (non-WASI) wasm targets.

We can keep this behavior for backwards-compatibility, but then only when targeting an unknown/none OS. We already do that in 55-target-wasm-naked.conf nowadays, via the -link-internally (=> use integrated lld with wasm-ld CLI interface) - but only if LLD integration was enabled at build-time.

So the compiler special case here would only be needed without LLD integration. Not sure that's worth the trouble, incl. the link_WebAssembly lit complication (looking for an external wasm-ld), which I haven't gotten rid of yet.

In theory, using most modern system clang as link driver for bare-metal Wasm should be fine? wasm-ld is a standard part of LLVM distributions nowadays.

One notable exception is (at least) macOS 15's clang. So you'll have to have either MacPorts/Homebrew LLVM/Clang available to use as -gcc, or use wasi-sdk's (or emsdk's).

But if we use -link-internally by default, then you probably won't notice the difference most of the time.

Oh right - I've just tested this with my system-default clang 18, and it works with an extra -Xcc=-nostdlib:

$ bin/ldc2 -mtriple=wasm32-unknown-unknown -v ../ldc/tests/codegen/wasm.d -link-internally=false -Xcc=-nostdlib -Xcc=-v […] Did not find C cross-compiler: `wasm32-unknown-unknown-gcc` Did not find C cross-compiler: `wasm32-unknown-unknown-clang` Found C cross-compiler: `/usr/bin/clang` /usr/bin/clang --target=wasm32-unknown-unknown wasm.o -o wasm.wasm -Xlinker -z -Xlinker stack-size=1048576 -Xlinker --stack-first -nostdlib -Wl,--gc-sections […] "/usr/bin/wasm-ld-18" -m wasm32 -L/usr/lib wasm.o -z stack-size=1048576 --stack-first --gc-sections -o wasm.wasm

So yeah, that should be good enough. Noone has requested an ld CLI interface for other targets either, so...

kinke · 2026-08-14T17:25:26Z

The druntime unittest failure was apparently due to too simplistic pthread stubs (so I guess one has to explicitly opt into emulated pthreads support): https://github.com/emscripten-core/emscripten/blob/6313a2d67a92c3e3b449f48e2fc9882d7e45ff3c/system/lib/pthread/library_pthread_stub.c#L222-L224

The timezone stuff is a bit of a PITA; I got the testrunners to include and be able to read the host runner's /usr/share/zoneinfo directory, but e.g. the TZ env-var support seems to be enabled in standalone-wasm mode only, which causes more Phobos unittest regressions (I/O related): https://github.com/emscripten-core/emscripten/blob/6313a2d67a92c3e3b449f48e2fc9882d7e45ff3c/system/lib/libc/musl/src/time/__tz.c#L136-L276 (USE_EXTERNAL_ZONEINFO is defined unless using the standalone-wasm mode)

So it's probably best to follow the CRuntime_WASI exclusions wrt. timezone stuff, not worth the trouble; users will hardly bake timezone files into their binaries anyway.

kinke · 2026-08-15T17:01:05Z

Ready for review now.

QuantumSegfault · 2026-08-15T20:10:46Z

    append("-Wl,-z,stack-size=1048576 -Wl,--stack-first" LD_FLAGS)

+    if("${TARGET_SYSTEM}" MATCHES "Emscripten")
+        append("-sALLOW_MEMORY_GROWTH" LD_FLAGS)


Do we want to enable this by default in ldc2.conf?

If not maybe this block should be moved outside of
(normally inherited from... if block to be less confusing

Yeah I'm not sure how likely this is going to be needed for user apps as well. IIRC, Emscripten defaults to something like 20 MB, which does sound really low for D with GC.

Do you know how wasmtime/wasi-libc handles this? All dynamic by default?

I believe so.

QuantumSegfault · 2026-08-15T21:04:07Z

Some of these values are incorrect.

I think you based these of the _POSIX_* values. Some of these have normal values.

#define NAME_MAX 255 #define PATH_MAX 4096 #define PIPE_BUF 4096

Oh, thx for checking so thoroughly! Yeah they were all based on the POSIX_ ones; the NAME_MAX of 14 or so did sound weird. Will fix.

Let's make importc_compare detect mismatching numerical constants for us: dlang/dmd#23618

Currently yields this for Emscripten here:

Collected 270 C types. Collected 1333 numerical C constants. Error: Constant core.stdc.stdint.WCHAR_MIN diverges: 0 (D) vs. -2147483648 (ImportC) Error: Constant core.stdc.stdint.WCHAR_MAX diverges: 1114111 (D) vs. 2147483647 (ImportC) Error: Constant core.stdc.stdint.WINT_MIN diverges: 0 (D) vs. -2147483648 (ImportC) Error: Constant core.stdc.signal.SIG_IGN diverges: 1 (D) vs. 4294967294 (ImportC) Error: Constant core.stdc.limits.MB_LEN_MAX diverges: 2 (D) vs. 4 (ImportC) Error: Constant core.stdc.math.math_errhandling diverges: 3 (D) vs. 2 (ImportC) Error: Constant core.stdc.wchar_.WEOF diverges: 65535 (D) vs. 4294967295 (ImportC)

QuantumSegfault · 2026-08-16T04:12:36Z

New changes look good.

Regarding the merging down of the changes made during WASI upstreaming, there was one issue I noticed.

The version gate for the unittest in typecons.d on line 3553 should have been deleted, as the versioning was moved inside the unittest.

Ah alright, missed one of these (unfortunately no merge conflict for these) - thx for spotting!

…ept for generally broken MB_LEN_MAX]

kinke force-pushed the emscripten branch from 1143884 to 82063c8 Compare August 10, 2026 13:16

kinke added 2 commits August 10, 2026 15:38

Add some primitive Emscripten support, based on WASI

80bccc9

CI: Add Emscripten job

e5da7df

kinke force-pushed the emscripten branch from 82063c8 to e5da7df Compare August 10, 2026 13:38

[try building Phobos too]

1f50a08

kinke force-pushed the emscripten branch from 9f952ea to 1f50a08 Compare August 10, 2026 14:21

kassane mentioned this pull request Aug 10, 2026

D tracking upstream issues floooh/sokol-d#82

Open

9 tasks

kinke added 4 commits August 10, 2026 16:38

[ignore unittest failures, and try running the Phobos debug testrunne…

9ed0812

…r too]

[fix linking with emcc]

a4e9abd

[enable addon-package smoke test for Emscripten too]

f75de5e

[add importc_compare test]

a825d0c

[druntime: Fix some issues reported by importc_compare]

834c6d1

kinke added 3 commits August 12, 2026 20:15

[fix core.sys.posix.sys.types and core.stdc.limits]

918f918

Based on the C+ headers.

[fix core.sys.posix.sys.stat]

8771d6e

[fix core.sys.posix.sys.socket]

e4616bf

kinke force-pushed the emscripten branch 7 times, most recently from dc050c1 to b03eb55 Compare August 13, 2026 17:52

Emscripten: Switch from predefined CRuntime_WASI to CRuntime_Musl

f342c2c

kinke force-pushed the emscripten branch from b03eb55 to f342c2c Compare August 13, 2026 18:13

[CI: Try mounting host timezone DB into node process]

06c29f2

QuantumSegfault reviewed Aug 13, 2026

View reviewed changes

kinke commented Aug 13, 2026

View reviewed changes

kinke added 5 commits August 13, 2026 22:33

[finish removal of wasm-ld linker special case]

346bf95

[add -Xcc=-nostdlib to 55-target-wasm-naked.conf]

2d81f40

[avoid warning wrt. ignored -Xcc switches when using -link-internally]

7ef92df

[fix core.sync.event unittest failure]

ca0e64f

[try using default Posix timezone data dir]

4459e8d

kinke force-pushed the emscripten branch 3 times, most recently from 30b5ac7 to 84ae082 Compare August 14, 2026 18:35

[Phobos: Hack around lacking TZ env var support]

2830c39

kinke force-pushed the emscripten branch from 84ae082 to 2830c39 Compare August 14, 2026 18:49

kinke added 2 commits August 15, 2026 18:07

[polish]

7cbdd31

[changelog]

9beaff6

kinke changed the title ~~WIP: Improve Emscripten support~~ Emscripten: Add druntime & Phobos support Aug 15, 2026

kinke force-pushed the emscripten branch from 5653c66 to 9beaff6 Compare August 15, 2026 16:14

kinke marked this pull request as ready for review August 15, 2026 17:00

kinke force-pushed the emscripten branch from e1d1ed8 to 0dc632b Compare August 15, 2026 20:57

QuantumSegfault suggested changes Aug 16, 2026

View reviewed changes

kinke added 2 commits August 16, 2026 11:25

[polish phobos]

33d6afb

[fix core.stdc.limits]

aad1338

kinke force-pushed the emscripten branch from 0dc632b to aad1338 Compare August 16, 2026 09:30

kinke added 2 commits August 16, 2026 15:07

[fix remaining mismatching constants reported by importc_compare, exc…

1956ff6

…ept for generally broken MB_LEN_MAX]

[oh, Phobos depends on wchar_t being a Unicode char type, not int]

e18b055

Uh oh!

Uh oh!

Conversation

kinke commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kinke commented Aug 10, 2026

Uh oh!

QuantumSegfault commented Aug 10, 2026

Uh oh!

kinke commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kinke commented Aug 13, 2026

Uh oh!

QuantumSegfault commented Aug 13, 2026

Uh oh!

kinke commented Aug 13, 2026

Uh oh!

QuantumSegfault commented Aug 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinke Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinke commented Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kinke commented Aug 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinke Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinke Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kinke commented Aug 10, 2026 •

edited

Loading

kinke commented Aug 10, 2026 •

edited

Loading

kinke Aug 13, 2026 •

edited

Loading

kinke commented Aug 14, 2026 •

edited

Loading

kinke Aug 16, 2026 •

edited

Loading

kinke Aug 16, 2026 •

edited

Loading