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. |
|
|
|
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. |
|
|
|
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 rust-lang/libc#2272 This should help with rust-lang#90044
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
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.
9c7500e
to
bd287fa
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
|
Damn, this can't be backported to beta as #90623 (on which this builds now) was after the beta fork. |
|
Whoops, didn't notice that this got updated, sorry. Unfortunately didn't find time to push through the libc cascade all the way, so it looks like this will be it for now. We can figure out if #90681 will fix it on the next train, when we have the luxury of time. |
|
Ah damn. |
|
@pnkfelix It seems this PR can't land on beta, but I agree with Hans' remarks on Zulip regarding the severity of the regression. I have no idea how we should proceed in terms of mitigation. Brainstorming alternatives in full-on "throw spaghetti at wall" mode:
|
|
I can open a minimal, functionally equivalent PR against beta (just restricting aarch64 outline atomics to glibc) and test that thoroughly. But I don't know if policy allows (non-backport) PRs that land only in beta. |
|
Sometimes we do point releases, so I can't imagine it's completely banned? I am not familiar with that nuance, however. |
|
Though, speaking of host tools guarantees: |
|
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. |
|
|
…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


The introduced dependency on
getauxvalcauses linking problems with musl, making compiling any binaries foraarch64-unknown-linux-muslimpossible 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.
The text was updated successfully, but these errors were encountered: