Hi I'm trying to understand the wasi-libc's sysroot structure and why it is what it is.
Firstly, inside the sysroot/lib directory, we see
root@2299d4e20d1f:/wasi-sdk/dist/wasi-sysroot/lib# ls
wasm32-wasi wasm32-wasi-threads wasm32-wasip1 wasm32-wasip1-threads wasm32-wasip2
is there some specific reason we have to divide these directories and each of them has its own libc.a? We are only using one of these at a time?
Besides, I've been trying to implement my own libc for wasm, and I build my own sysroot with only write
syscall and stpcpy
string function, it worked where I use llvm-ar to put a minimal libc.o and stpcpy.o into a libc.a
file. So I suppose the libc.a file is actually the core of a wasm sysroot? Then why there's still a libc.so
inside wasi-sdk's sysroot/lib/wasm32-wasi/
? Is a libc.a
along enough?
Currently, I also compiled parts (like the entire string library) of glibc into WASM object files, but not yet combine them into a sysroot, and I'm asking the questions above just trying to get some hints for how to achieve this. Thank you guys!
@Coulson Liang those directories correspond to different targets (sometimes called "triples" though here they don't have three parts); each is a slightly different configuration of WASI. For example, wasip1
and wasip2
target different versions of the WASI APIs, "preview 1" and "preview 2" respectively; and the threads variants assume the WASI-threads proposal is present. These need different libc builds because they require different imports.
I don't know why a .so
file is present; Wasm doesn't support native shared objects (dynamic libraries) currently; perhaps it's an artifact of a more generic build infrastructure that also supports systems with .so's, I'm not sure
Regarding libc.so
vs. libc.a
: the former is for dynamic linking and the latter is for static linking.
@Chris Fallin it does, actually! https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md
Python uses (pseudo-)dynamic linking heavily to support native extensions using wasm-tools component link
Oh neat, I had no idea it was built out to that level!
Yeah, you can even use dlopen
/dlsym
from within a component to resolve symbols at runtime.
oh so, as there's only libc.a without libc.so for some targets, using these sysroot targets makes all .wasm outputs statically linked?
Yeah, there's some non-PIC assembly code in the wasm32-wasip1-threads
target, for example, so we haven't gotten around to enabling .so builds there
Sure thank you Joel!
I'm also curious why there are so many .a files in the sysroot
crt1-command.o libc-printscan-long-double.a libm.a libwasi-emulated-getpid.a
crt1-reactor.o libc-printscan-no-floating-point.a libpthread.a libwasi-emulated-mman.a
crt1.o libc.a libresolv.a libwasi-emulated-process-clocks.a
libc++.a libc.imports librt.a libwasi-emulated-signal.a
libc++abi.a libcrypt.a libsetjmp.a libxnet.a
libc++experimental.a libdl.a libutil.a
If I build my own libc, putting everything into just libc.a
is okay or not?
The libwasi-emulated-*
ones contain stubbed symbols for not-actually-supported features which third-party devs can optionally use to get stuff compiling (and hopefully not actually call at runtime, since they won't work). We keep those separate so the developer has to opt in explicitly and understand they're just stubs.
the libc-printscan-
ones allow the developer to slim down their build by not including stuff they don't need (like formatting long double
values).
and libm.a
, libpthread.a
etc. are just conventionally separate libraries even outside the Wasm world
Oh I see I see, so putting everything together is not a good practice, but it seems fine for testing right?
Do we actually have documentation on these details, I mean, for wasi-libc, I didn't see much docs on the website or github
If you're writing your own libc, you can do anything you want :) Putting everything in a single file sounds fine to me, anyway.
I don't know of any docs, sorry. I've learned what I know by reading comments in the Makefile and asking questions.
Haha sure, thank you again for all these explanations!
Last updated: Dec 23 2024 at 12:05 UTC