-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
std: Don't use linkat on the wasm32-wasi* targets
#149864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This commit is a follow-up to 147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc/690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
| any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_env = "nto70") => { | ||
| // VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead. POSIX leaves | ||
| // it implementation-defined whether `link` follows symlinks, so rely on the | ||
| // `symlink_hard_link` test in library/std/src/fs/tests.rs to check the behavior. | ||
| // Android has `linkat` on newer versions, but we happen to know `link` | ||
| // always has the correct behavior, so it's here as well. | ||
| any( | ||
| // VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead. | ||
| // POSIX leaves it implementation-defined whether `link` follows | ||
| // symlinks, so rely on the `symlink_hard_link` test in | ||
| // library/std/src/fs/tests.rs to check the behavior. | ||
| target_os = "vxworks", | ||
| target_os = "redox", | ||
| target_os = "espidf", | ||
| // Android has `linkat` on newer versions, but we happen to know | ||
| // `link` always has the correct behavior, so it's here as well. | ||
| target_os = "android", | ||
| // wasi-sdk-29-and-prior have a buggy `linkat` so use `link` instead | ||
| // until wasi-sdk is updated (see WebAssembly/wasi-libc#690) | ||
| target_os = "wasi", | ||
| // Other misc platforms | ||
| target_os = "horizon", | ||
| target_os = "vita", | ||
| target_env = "nto70", | ||
| ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a note for this I took the liberty to reformat the line to be less long and arrange the comments to apply to the platform-in-question too.
|
Yup, makes sense. |
|
For future reference, the relevant code in wasi-libc is which indeed calls |
…joboet std: Don't use `linkat` on the `wasm32-wasi*` targets This commit is a follow-up to rust-lang#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
…joboet std: Don't use `linkat` on the `wasm32-wasi*` targets This commit is a follow-up to rust-lang#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
Rollup of 7 pull requests Successful merges: - #146794 (std: reorganize pipe implementations) - #148196 (Implement create_dir_all() to operate iteratively instead of recursively) - #148490 (dangling pointer from temp cleanup) - #149864 (std: Don't use `linkat` on the `wasm32-wasi*` targets) - #149885 (replace addr_of_mut with &raw mut in maybeuninit docs) - #149949 (Cleanup of attribute parsing errors) - #149969 (don't use no_main and no_core to test IBT) Failed merges: - #148847 (Share Timespec between Unix and Hermit) r? `@ghost` `@rustbot` modify labels: rollup
This commit is a follow-up to #147572 and the issue reported at the end of that PR where the
std::fs::hard_linkfunction is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip thelinkatfunction.