Sigil (0.17.8)

One dispatch entry on both backends

Bytecode web builds now export sigil_wasm_dispatch_event(type, payload), the typed entry native builds already had. JavaScript hands the app two strings and the app's sigil-web-dispatch-event handler receives them as string values: no Scheme source to build, no escaping to get wrong. A string result comes back through sigil_wasm_last_result_length / sigil_wasm_copy_result, and a handler that suspends on async work returns -2 and resumes via sigil_wasm_resume_async, the same flow the eval path uses.

Action needed for custom loaders: both backends now export the dispatch entry, so its presence no longer identifies a native build. Detect native via the sigil_wasm_native_start export instead. The stock loader is already updated; a loader still keying on sigil_wasm_dispatch_event will misdetect bytecode builds as native and fail to load their /lib files.

Build-cache reliability

Two fixes close the failure where builds run under different toolchain environments (two different guix shells, say) could poison each other's cached C objects and end in a silent, empty .wasm. The C-object cache now fingerprints the compiler's full toolchain environment, so different toolchains never share cache entries. Expect a one-time recompile of cached C objects after upgrading. And the wasm asyncify step now validates its output and fails the build loudly instead of leaving behind an empty module that a later build could mistake for already built.

The unbound-variable crash on the release-mode error path, fixed in 0.17.7, has been re-verified and its regression test is back in the suite.