Update how WASI toolchains are used in CI and bootstrap #123978
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
A-testsuite
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Nilstrieb |
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example. Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
alexcrichton
force-pushed
the
update-wasi-toolchain
branch
from
cfba7ed to
8bb9d30
Compare
| let root = PathBuf::from(std::env::var_os("WASI_SDK_PATH")?); | ||
| let compiler = match compiler { | ||
| Language::C => format!("{t}-clang"), | ||
| Language::CPlusPlus => format!("{t}-clang++"), |
There was a problem hiding this comment.
Out of interest, why is clang/clang++ prefixed with the target? That seems like an odd choice for the usually cross-compiling nature of clang/LLVM?
(Obviously not blocking here since it's not something we can change on the Rust side :)
There was a problem hiding this comment.
It's not necessarily required but it helps configure clang with the --target value. Clang has a feature that a target-prefixed executable doesn't need --target passed, and the wasi-sdk sysroot has a bunch of symlinks for wasi targets that all point at a single clang executable, so it's all the same executable just a name-based-dispatch executable.
There was a problem hiding this comment.
Ah I didn't know about that feature. Sounds good.
|
@bors r+ rollup=iffy |
bors
added
S-waiting-on-bors
|
I just want to note that for Fedora and RHEL, we don't have the full |
|
Thanks for the heads up, good to know! The one caveat with this PR is that the lookup within Will that cause problems though? If so I can rename |
|
Yeah, a direct |
|
Ok cool, I'll add that as an option on top of |
…r=Mark-Simulacrum Update how WASI toolchains are used in CI and bootstrap This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example. Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
|
Looking over the logs there it seems like the job was cancelled although I am not certain of this as I know I've seen failured on GitHub Actions look like cancellations in the past. Is there perhaps a better way to figure out what failed? Or failing that, could this be queued for a retry? |
|
As long as it's not a timeout, which this doesn't appear to be, then I think we can just retry. @bors retry |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (becebb3): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 677.262s -> 677.135s (-0.02%) |
7 participants
This commit updates how the WASI targets are configured with their toolchain. Long ago a
config.tomloption ofwasi-rootwas added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of thewasm32-wasip1target, for example.Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates
bootstrapto recognize when this is configured. This means that with$WASI_SDK_PATHconfigured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such aswasm32-wasip2andwasm32-wasip1-threadswhere the wasi-sdk release now has libraries for all targets bundled within it.