-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Restrict aarch64 outline atomics to glibc for now. #90044
Restrict aarch64 outline atomics to glibc for now. #90044
Conversation
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
I may not understand how the For example, right now you can't get a successful build on |
Allowing But I can move the outline atomics block before |
If an updated libc with rust-lang/libc#2272 fixes it, then this is no longer needed. Let's wait for that. @rustbot label -S-waiting-on-review +S-waiting-on-author |
This issue does not only occur with a libc dependency in the tree. Even a no-deps Hello World program triggers it. |
Yes, but the std library uses rust-lang/libc. Having an unbundled libc.a at the right place in link order will resolve this problem as well. |
😩 Sorry for missing this. Let me see... |
So it looks like we accidentally broke musl on aarch64 because we aren't compiling musl in a way that is convenient for musl (already a known factor, really, but I didn't expect it to cause an issue here), and:
so this one should wait a little for that but not a long time, correct? Alright, I will keep this on my radar. |
Speaking of radar, it looks like we bumped LLVM to min 12. Accordingly, #90623 was opened, which remedies the FIXME and also will pose a merge conflict with this PR. I would stop the rollup, but currently we seem to be inclined to let things ride for a few nights and hope a new libc fixes it, so might as well let it ride. It also addresses the second commit in this set. |
☔ The latest upstream changes (presumably #90631) made this pull request unmergeable. Please resolve the merge conflicts. |
If the libc update does not fix it, I will update this PR to just remove the |
Changelog: https://github.com/rust-lang/libc/releases/tag/0.2.107 Primarily intended to pull in fd331f65f214ea75b6210b415b5fd8650be15c73 This should help with rust-lang#90044
…itor Update libc to 0.2.107 Changelog: https://github.com/rust-lang/libc/releases/tag/0.2.107 Primarily intended to pull in rust-lang/libc@fd331f6 This should help with rust-lang#90044
The introduced dependency on `getauxval`causes linking problems with musl, see rust-lang#89626.
I find this state of affairs baffling but I am going to approve this commit with a note here that it can't actually be backported in as-is form, so that this issue doesn't persist into the next beta cut. |
📌 Commit bd287fa has been approved by |
…mics_for_musl, r=workingjubilee Restrict aarch64 outline atomics to glibc for now. The introduced dependency on `getauxval` causes linking problems with musl, making compiling any binaries for `aarch64-unknown-linux-musl` impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see rust-lang#89626. This is a workaround until libc>0.2.108 is merged.
…mics_for_musl, r=workingjubilee Restrict aarch64 outline atomics to glibc for now. The introduced dependency on `getauxval` causes linking problems with musl, making compiling any binaries for `aarch64-unknown-linux-musl` impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see rust-lang#89626. This is a workaround until libc>0.2.108 is merged.
…laumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#89542 (Partially stabilize `duration_consts_2`) - rust-lang#90044 (Restrict aarch64 outline atomics to glibc for now.) - rust-lang#90420 (Create rustdoc_internals feature gate) - rust-lang#91075 (Reduce prominence of item-infos) - rust-lang#91151 (Fix test in std::process on android) - rust-lang#91179 (Fix more <a> color) - rust-lang#91199 (rustdoc: Add test for mixing doc comments and attrs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is a functionally equivalent, minimally invasive backport of rust-lang#90044. backport-of: nothing
The host tools are linked against shared musl in CI, which works fine. This is only an issue with +crt-static, which is the default for the aarch64-unknown-linux-musl target. |
Oh, then the severity of this is somewhat reduced, as musl-based distros patch rustc's musl targets to default to -crt-static (a patch we will eventually take up, and to some degree this hammers home why we should). |
Changelog: https://github.com/rust-lang/libc/releases/tag/0.2.107 https://github.com/rust-lang/libc/releases/tag/0.2.108 Primarily intended to pull in fd331f65f214ea75b6210b415b5fd8650be15c73 This should help with rust-lang#90044
Update libc to 0.2.108 Changelog: https://github.com/rust-lang/libc/releases/tag/0.2.107 https://github.com/rust-lang/libc/releases/tag/0.2.108 Primarily intended to pull in rust-lang/libc@fd331f6 This should help with rust-lang#90044
This is a functionally equivalent, minimally invasive backport of rust-lang#90044, which fixes the problem that compiling any binary with the target aarch64-unknown-linux-musl fails unless lld is used for linking (rust-lang#89626). I have tested this backport by building aarch64-unknown-linux-gnu, installing the std libraries for the -musl and -gnu variants in rustc-beta-aarch64-unknown-linux-gnu/rustc/lib/rustlib and running helloworld successfully for both targets on arm64 hardware.
…imulacrum [stable] 1.57.0 artifacts This is the standard beta->stable promotion, and includes a last-minute backports of: * rust-lang#90044 via inclusion of rust-lang#91220. * [beta] Don't treat unnormalized function arguments as well-formed rust-lang#91242 r? `@Mark-Simulacrum`
The introduced dependency on
getauxval
causes linking problems with musl, making compiling any binaries foraarch64-unknown-linux-musl
impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see #89626.This is a workaround until libc>0.2.108 is merged.