Prove the wasm archive is usable before it becomes a release asset - #18
Merged
Conversation
Ten releases have shipped a browser-wasm archive that nothing ever linked. The archive itself turned out to be fine -- Evergine.Bindings .JoltPhysics packed it under a name no DllImport could match and had no buildTransitive targets file, so the fault was downstream -- but nothing in this repository could have told the difference, and that is what this fixes. The eleven C suites do not cover it: they are built and run natively, so they prove the library works and say nothing about whether .NET can link it. The build only proves emcc accepted the sources. A .NET publish rather than an emcc link check, and the difference is the point. .NET links with its own flags -- -exception-model=wasm, a fixed wasm-opt feature list, no setjmp support library -- so an archive can satisfy emcc and be unusable by the only consumer this repository has. In CesiumC three separate blockers were found by a person running a publish by hand and none by the emcc check in the same job. It also covers what comes after linking: wasm-opt runs with a fixed feature list and an archive can link cleanly and then fail validation. The check calls into the library rather than merely referencing it, so the linker has to pull the members behind the calls, and creates the job system with no worker threads because there is no pthread here and JoltPhysics then runs jobs on the thread waiting at the barrier. Verified out of band before this was written: the archive from the published 2026.8.4.12, renamed to JoltC.a, links and runs under node. So this step should be green on the first try, and its value is the release where it will not be.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Ten releases shipped a browser-wasm archive that nothing ever linked.
The archive itself turned out to be fine.
Evergine.Bindings.JoltPhysicspacked it under a name no DllImport could match and shipped nobuildTransitivetargets file, so the fault was downstream (JoltPhysics.NET#12 fixes it). But nothing here could have told the difference, and that is what this PR is for.The eleven C suites do not cover this: they build and run natively, so they prove the library works and say nothing about whether .NET can link it. The build only proves emcc accepted the sources.
Why a .NET publish and not an emcc link check
.NET links with its own flags —
-exception-model=wasm, a fixedwasm-optfeature list, no setjmp support library — so an archive can satisfy emcc and still be unusable by the only consumer this repository has. In CesiumC three separate blockers were found by a person running a publish by hand and none by the emcc check sitting in the same job. It also covers the step after linking:wasm-optruns with a fixed feature list, and an archive can link cleanly and then fail validation.The check calls into the library rather than referencing it, so the linker has to pull the members behind the calls, and it creates the job system with
numThreads = 0— no pthread here, and JoltPhysics then runs jobs on the thread waiting at the barrier.Verified out of band before writing this: the archive from the published
2026.8.4.12, renamed toJoltC.a, links and runs under node. So this step should be green on the first try. Its value is the release where it will not be.