Sam Clegg

You could also have two different sysroots without changing the triple: ``` $ clang --sysroot=/path/to/preview1 --target wasm32-wasi $ clang --sysroot=/path/to/preview2 --target wasm32-wasi ``` I seem to remember from previous discussions...

> Following Rust here to me isn't just inertia, it's well-motivated independently. Thanks for all the clarifying data, my intent here is was only to make sure we were considering...

> This means that preexisting code interoperating with libc file descriptors and `wasi_snapshot_preview1` manually would be broken on the preview2 target. I agree there may be ABI differences but with...

We are getting off topic here but I can think of a couple more arguments for a given language runtime to use wasi-libc rather than directly binding to wasi syscall...

I guess there is nothing POSIX/musl that works like https://man7.org/linux/man-pages/man3/gnu_get_libc_version.3.html? Perhaps we could fit it into the output of `uname`? Or is that too hacky?

> @sbc100 We actually use the C function `uname()` on Linux already If thats the case then is the thing you really want to know the the OS/host version, and...

Re-reading your reply it look like you are indeed wanting the OS version. In that case I don't think that version of wasi-libc is important/relevant here and WASI is unlikely...

I think it could make sense add the version of WASI we are using to the uname()? e.g. `wasip1` vs `wasip2`. But I don't think the version of wasi-sdk/wasi-libc makes...

> @sbc100, the `wasip1`/`wasip2` string seems valuable-ish but I think they're asking for more: i.e., to reproduce a bug they're going to need all of that toolchain information. What do...

> @sbc100, the `wasip1`/`wasip2` string seems valuable-ish but I think they're asking for more: i.e., to reproduce a bug they're going to need all of that toolchain information. What do...