Enable statx on supported musl versions#154981
Enable statx on supported musl versions#154981strophy wants to merge 1 commit intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
r? @jhpratt rustbot has assigned @jhpratt. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Failed to set assignee to
|
This comment has been minimized.
This comment has been minimized.
strophy
changed the title
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
| #[cfg(all(target_os = "linux", target_env = "gnu"))] | ||
| #[cfg(target_os = "linux")] | ||
| use crate::sys::weak::syscall; |
There was a problem hiding this comment.
This still doesn't seem quite right. Why are we using weak linkage and dynamic detection when we know the version of musl we link?
There was a problem hiding this comment.
Some discussion about this pattern here #t-libs > Problems with `syscall!`
There was a problem hiding this comment.
I'm more of a package maintainer and am relatively unfamiliar with both Rust and libc, so the conversation you referenced is a bit over my head unfortunately. What is the preferred approach here, how should I amend my PR?
There was a problem hiding this comment.
Would it be possible to config things such that statx remains "maybe available" on GNU with syscall! and the fallback, like it is now, but then on musl it's treated as unconditionally available? I.e. call libc::statx directly.
If this isn't easily possible then it's probably fine, this config is pretty messy. But the Zulip thread I linked is talking about how LTO is kind of buggy when there are both strong (calling the function directly) and weak (using syscall!) definitions, which I expect we may hit with the current implementation.
There was a problem hiding this comment.
It sounds a lot simpler to me to just always use syscall! here, even if it could be slightly faster on musl.
6 participants
Rust has feature-gated fs statx calls to gnu libc only. This feature was added to musl libc in the 1.2.5 release, which was in turn included in Rust 1.93.0, see #142682
There is a stale feature gate that is still blocking access to statx calls, even though this is now available in musl libc through the libc crate v0.2.175+, see rust-lang/libc#3976
This PR enables the feature. Note that this will likely cause build breakages anywhere rustix is used, and the issue has already popped up in the rustix repo bytecodealliance/rustix#1496 for archs that never supported musl <1.2.5
This is my first PR here and I need some help coordinating between all these moving parts. @Gankra could you help maybe? Thanks!
More refs:
#67774
vectordotdev/vector#23813
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98199
r? @Gankra