surviving wasm
Julian Fondren
julian.fondren at gmail.com
Wed Dec 13 21:15:47 UTC 2023
On Wednesday, 13 December 2023 at 20:40:20 UTC, monkyyy wrote:
> so long term planning on wasm raylib; I want compatibility with
> the good parts of the std, the std is causal about using libc
> while ldc-wasm half-baked implication is missing a bunch of
> basically worthless symbols but given the std is 1 million
> lines of code it will be a perennial problem that I make
> something work natively, I try it in wasm, it breaks citing a
> random core lib at a random line; the options I know about are:
>
> 1. use a "team betterc" personal std that doesn't have the apis
> I want, apis I know and probably limited
> 2. merge "use libc less" upstream to a std that has been slow
> to merge changes and probably doesnt care about wasm
> 3. fork the std
> 4. maintain patches to the std that go in and rewrite them live
> with root :D what could go wrong
> 5. make my own personal std that matches the std api of the
> parts I use
>
> I hate all these options
6. statically build against musl and include it in the wasm
binary. Since phobos is slow to change, its libc dependencies
will also be slow to change, and you can work on reducing how
much musl goes into the binary. Musl's MIT-licensed and D has
ImportC; maybe this can be upstreamed as a pseudo-libc-less build
option. People who don't care about wasm may still care about
dodging glibc due to binary portability hassles with deployment
to older servers. ldc already uses musl on Alpine Linux, popular
with containers.
More information about the Digitalmars-d-learn
mailing list