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.
