Skip to content

Conversation

hkratz
Copy link
Contributor

@hkratz hkratz commented Oct 19, 2021

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 #89626.

This is a workaround until libc>0.2.108 is merged.

@rust-highfive
Copy link
Contributor

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 19, 2021
@oli-obk
Copy link
Contributor

oli-obk commented Oct 19, 2021

r? @workingjubilee

@jbg
Copy link

jbg commented Oct 19, 2021

I may not understand how the features argument is interpreted, but shouldn't this be before the -C target-feature processing on line 417? It should be defaulting outline-atomics to on, but right now it seems to be forcing it to on, so -C target-feature=-outline-atomics doesn't do anything.

For example, right now you can't get a successful build on aarch64-unknown-linux-musl by setting RUSTFLAGS="-C target-feature=-outline-atomics". Presumably even after this patch, a glibc user can't disable the outline-atomics target feature if they want to.

@hkratz
Copy link
Contributor Author

hkratz commented Oct 19, 2021

Allowing -C target-feature=-outline-atomics to override this setting would definitely be an improvement, but it would not work because the std library would still be compiled with it enabled.

But I can move the outline atomics block before -C target-feature processing code as well (later feature specs override earlier ones).

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 28, 2021
@hkratz
Copy link
Contributor Author

hkratz commented Nov 4, 2021

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

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 4, 2021
@jbg
Copy link

jbg commented Nov 4, 2021

This issue does not only occur with a libc dependency in the tree. Even a no-deps Hello World program triggers it.

@hkratz
Copy link
Contributor Author

hkratz commented Nov 4, 2021

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.

@workingjubilee
Copy link
Member

😩 Sorry for missing this. Let me see...

@workingjubilee
Copy link
Member

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:

  • we may find out that a recent libc crate update fixes it when it lands
  • but we should try to get this resolved before it hits stable
  • and another PR against rust-lang/rust offers a known permanent fix Eventually

so this one should wait a little for that but not a long time, correct? Alright, I will keep this on my radar.

@workingjubilee
Copy link
Member

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.

@bors
Copy link
Collaborator

bors commented Nov 6, 2021

☔ The latest upstream changes (presumably #90631) made this pull request unmergeable. Please resolve the merge conflicts.

@hkratz
Copy link
Contributor Author

hkratz commented Nov 6, 2021

If the libc update does not fix it, I will update this PR to just remove the +outline-atomics feature from the aarch64_unknown_linux_musl target spec.

@workingjubilee workingjubilee reopened this Nov 8, 2021
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 8, 2021
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 9, 2021
The introduced dependency on `getauxval`causes linking
problems with musl, see rust-lang#89626.
@workingjubilee
Copy link
Member

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.
@bors r+ rollup=always

@bors
Copy link
Collaborator

bors commented Nov 24, 2021

📌 Commit bd287fa has been approved by workingjubilee

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 24, 2021
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Nov 24, 2021
…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.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Nov 24, 2021
…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.
This was referenced Nov 24, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 24, 2021
…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
@bors bors merged commit cbe563a into rust-lang:master Nov 25, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 25, 2021
hkratz added a commit to rusticstuff/rust that referenced this pull request Nov 25, 2021
This is a functionally equivalent, minimally invasive backport of rust-lang#90044.

backport-of: nothing
@hkratz
Copy link
Contributor Author

hkratz commented Nov 25, 2021

Though, speaking of host tools guarantees: How did the original regression land if this issue blocks even linking a simple "Hello, world!"?

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.

@hkratz hkratz deleted the disable_arm_outline_atomics_for_musl branch November 25, 2021 19:54
@workingjubilee
Copy link
Member

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).

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 28, 2021
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2021
Mark-Simulacrum pushed a commit to Mark-Simulacrum/rust that referenced this pull request Nov 29, 2021
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.
@Mark-Simulacrum Mark-Simulacrum modified the milestones: 1.58.0, 1.57.0 Nov 29, 2021
@Mark-Simulacrum Mark-Simulacrum added beta-accepted Accepted for backporting to the compiler in the beta channel. and removed beta-nominated Nominated for backporting to the compiler in the beta channel. labels Nov 29, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 29, 2021
…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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants