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