Add the wasm32-wasi-pthread output to the sysroot

[abrown]

Now that the wasm32-wasi-pthread target in wasi-libc has been worked on for some amount of time, this change allows it to be released as a part of wasi-sdk packages. It should be noted somewhere (a compiler warning? README?) that this new target is not entirely stable, but that can be added as a follow-on commit. This change is mainly focused on ensuring that the build artifacts contain the new objects.

[abrown]

One note on this: I think we may want to change the name of this target to wasm32-wasi-threads in a future commit to wasi-libc and pull that in to wasi-sdk. The reason is that I think we should try to avoid confusion if at all possible and over in rustc (rust-lang/compiler-team#574) it is more likely that wasm32-wasi-threads is selected as the target name, since pthreads are not relevant to the Rust standard library.

[yamt]

see #274

[sbc100]

One note on this: I think we may want to change the name of this target to wasm32-wasi-threads in a future commit to wasi-libc and pull that in to wasi-sdk. The reason is that I think we should try to avoid confusion if at all possible and over in rustc (rust-lang/compiler-team#574) it is more likely that wasm32-wasi-threads is selected as the target name, since pthreads are not relevant to the Rust standard library.

Are you sure pthreads is not relevant to the Rust standard library? I feel like I've asked this question before but doesn't the rust standard library want to use pthreads under the hood? Doesn't it do this already on platforms like linux and mac? Wouldn't it make it hard to link in other C libraries that are built on pthreads if rust doesn't use pthreads but instead rolled its own threads on top of wasi-thread-spawn (or equivalently if rust use close directly instead of pthread_create on linux?)

[abrown]

Are you sure pthreads is not relevant to the Rust standard library? I feel like I've asked this question before but doesn't the rust standard library want to use pthreads under the hood?

Oh, I'm not saying it shouldn't and in fact I think I've discussed with a few people that we might want to do just that--use wasi-libc's pthread support. What I'm trying to say is that "pthread" as a name could confuse things; whether or not the Rust stdlib uses pthreads is kind of an internal detail that we probably don't want users getting hung up on, IMO. It seems preferable that users have 1) a consistent target and 2) a target name that reminds us of the Wasm threads proposal and the wasi-threads proposal, not one use of it. (Hopefully I explained this well over in WebAssembly/wasi-libc#381).

[yamt]

#274 has been containing the identical change and it's more complete IMO.
it has been a draft because i'm still waiting for a critical fix in wasi-libc: WebAssembly/wasi-libc#372

[abrown]

I agree that #274 is more complete. I think I will close this one; @yamt, can you modify #274 to use the new target name that just merged, wasm32-wasi-threads?