Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Can't cross-build rustc for aarch64-apple-darwin anymore #76733

Closed
glandium opened this issue Sep 15, 2020 · 11 comments · Fixed by #76799
Closed

Can't cross-build rustc for aarch64-apple-darwin anymore #76733

glandium opened this issue Sep 15, 2020 · 11 comments · Fixed by #76799
Labels
A-cross Area: Cross compilation C-bug Category: This is a bug. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@glandium
Copy link
Contributor

With the following config.toml:

[build]
build = "x86_64-apple-darwin"
host = ["aarch64-apple-darwin"]
target = ["aarch64-apple-darwin"]

when building on a Apple Silicon DTK, you'd get an aarch64-apple-darwin rustc and libstd. That's not the case since #76415, where you only end up with an x86_64-apple-darwin compiler and libstd. There isn't even a build/aarch64-apple-darwin directory at all.
@glandium glandium added the C-bug Category: This is a bug. label Sep 15, 2020
@glandium
Copy link
Contributor Author

For the record, since multiple commits are involved in #76415, bisect points to 3193d52

@jyn514 jyn514 added A-cross Area: Cross compilation T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Sep 15, 2020
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Sep 15, 2020
@jyn514
Copy link
Member

jyn514 commented Sep 15, 2020

cc @Mark-Simulacrum

@Mark-Simulacrum
Copy link
Member

How are you invoking x.py?

I've just run src/ci/docker/run.sh dist-arm-linux, which has an almost-identical configuration, just targeting arm-unknown-linux-gnueabi instead of aarch64-apple-darwin, which runs x.py dist --host arm-unknown-linux-gnueabi --target arm-unknown-linux-gnueabi.

That gets me the following in build/dist:

cargo-nightly-arm-unknown-linux-gnueabi.tar.gz
cargo-nightly-arm-unknown-linux-gnueabi.tar.xz
clippy-nightly-arm-unknown-linux-gnueabi.tar.gz
clippy-nightly-arm-unknown-linux-gnueabi.tar.xz
llvm-tools-nightly-arm-unknown-linux-gnueabi.tar.gz
llvm-tools-nightly-arm-unknown-linux-gnueabi.tar.xz
miri-nightly-arm-unknown-linux-gnueabi.tar.gz
miri-nightly-arm-unknown-linux-gnueabi.tar.xz
rls-nightly-arm-unknown-linux-gnueabi.tar.gz
rls-nightly-arm-unknown-linux-gnueabi.tar.xz
rust-analysis-nightly-arm-unknown-linux-gnueabi.tar.gz
rust-analysis-nightly-arm-unknown-linux-gnueabi.tar.xz
rust-analyzer-nightly-arm-unknown-linux-gnueabi.tar.gz
rust-analyzer-nightly-arm-unknown-linux-gnueabi.tar.xz
rust-dev-nightly-arm-unknown-linux-gnueabi.tar.gz
rust-dev-nightly-arm-unknown-linux-gnueabi.tar.xz
rust-nightly-arm-unknown-linux-gnueabi.tar.gz
rust-nightly-arm-unknown-linux-gnueabi.tar.xz
rust-src-nightly.tar.gz
rust-src-nightly.tar.xz
rust-std-nightly-arm-unknown-linux-gnueabi.tar.gz
rust-std-nightly-arm-unknown-linux-gnueabi.tar.xz
rustc-dev-nightly-arm-unknown-linux-gnueabi.tar.gz
rustc-dev-nightly-arm-unknown-linux-gnueabi.tar.xz
rustc-nightly-arm-unknown-linux-gnueabi.tar.gz
rustc-nightly-arm-unknown-linux-gnueabi.tar.xz
rustfmt-nightly-arm-unknown-linux-gnueabi.tar.gz
rustfmt-nightly-arm-unknown-linux-gnueabi.tar.xz

I also see a build/aarch64-apple-darwin/stage2 directory and it contains a stage2 compiler, as expected.

x.py build doesn't work (still) in the sense that it doesn't assemble a compiler for you, but it does build all the components. This is due to the (prior) change in defaults where --stage 1 for a cross-compilation build doesn't really make a lot of sense, but is what we default to now.

@glandium
Copy link
Contributor Author

x.py build --stage 2 is what I was running, and before 3193d52, I'd get a build/aarch64-apple-darwin/stage2 directory. After, I don't get a build/aarch64-apple-darwin at all.

@glandium
Copy link
Contributor Author

x.py dist creates a build/aarch64-apple-darwin/stage2 tree but fails before actually filling it with

error: failed to test example in lint docs for `ill_formed_attribute_input` in /Users/glandium/rust/compiler/rustc_session/src/lint/builtin.rs:12: did not find lint `ill_formed_attribute_input` in output of example, got:
error[E0463]: can't find crate for `std`


error: aborting due to previous error


For more information about this error, try `rustc --explain E0463`.



command did not execute successfully: "/Users/glandium/rust/build/x86_64-apple-darwin/stage0-tools-bin/lint-docs" "--src" "/Users/glandium/rust/compiler" "--out" "/Users/glandium/rust/build/aarch64-apple-darwin/md-doc/rustc/src/lints" "--rustc" "/Users/glandium/rust/build/x86_64-apple-darwin/stage2/bin/rustc"
expected success, got: exit code: 1


failed to run: /Users/glandium/rust/build/bootstrap/debug/bootstrap dist

@Mark-Simulacrum
Copy link
Member

Hm, and that's on latest master? I guess I can try to reproduce this on a DTK, but I find it pretty odd that you're seeing different behavior than I am for essentially equivalent configurations, just different concrete targets...

Do you have anything else in config.toml?

@glandium
Copy link
Contributor Author

It was on latest master or close when I filed, which was 9b41541. My config.toml is literally what I pasted (didn't copy from config.toml.example).

@glandium
Copy link
Contributor Author

I can reproduce on current master (6af1bdd) on Linux with the following config.toml:

[build]
build = "x86_64-unknown-linux-gnu"
host = ["i686-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu"]

(no build/i686-unknown-linux-gnu) and if I revert 3193d52, it works again.

@Mark-Simulacrum
Copy link
Member

Okay, I've been able to reproduce. I guess something about the docker container (dist-arm-linux) is different perhaps? Or I wasn't building on the right commit before -- not sure.

Looking at fixing now.

@Mark-Simulacrum Mark-Simulacrum mentioned this issue Sep 16, 2020
Merged
@Mark-Simulacrum
Copy link
Member

Both bugs should be fixed by #76799.

@spastorino spastorino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 16, 2020
@spastorino
Copy link
Member

This looks more like T-infra than T-compiler, I guess I'd leave it up to @Mark-Simulacrum in case they want to prioritize it.

@spastorino spastorino added T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 16, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 19, 2020
@Dylan-DPC
Rollup merge of rust-lang#76799 - Mark-Simulacrum:fix-cross-compile-d…
ca47be8 
…ist, r=alexcrichton

Fix cross compiling dist/build invocations

I am uncertain why the first commit is not affecting CI. I suspect it's because we pass --disable-docs on most of our cross-compilation builders. The second commit doesn't affect CI because CI runs x.py dist, not x.py build.

Both commits are standalone; together they should resolve rust-lang#76733. The first commit doesn't really fix that issue but rather just fixes cross-compiled x.py dist, resolving a bug introduced in rust-lang#76549.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 19, 2020
@Dylan-DPC
Rollup merge of rust-lang#76799 - Mark-Simulacrum:fix-cross-compile-d…
a78660f 
…ist, r=alexcrichton

Fix cross compiling dist/build invocations

I am uncertain why the first commit is not affecting CI. I suspect it's because we pass --disable-docs on most of our cross-compilation builders. The second commit doesn't affect CI because CI runs x.py dist, not x.py build.

Both commits are standalone; together they should resolve rust-lang#76733. The first commit doesn't really fix that issue but rather just fixes cross-compiled x.py dist, resolving a bug introduced in rust-lang#76549.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 19, 2020
@Dylan-DPC
Rollup merge of rust-lang#76799 - Mark-Simulacrum:fix-cross-compile-d…
0dc29d7 
…ist, r=alexcrichton

Fix cross compiling dist/build invocations

I am uncertain why the first commit is not affecting CI. I suspect it's because we pass --disable-docs on most of our cross-compilation builders. The second commit doesn't affect CI because CI runs x.py dist, not x.py build.

Both commits are standalone; together they should resolve rust-lang#76733. The first commit doesn't really fix that issue but rather just fixes cross-compiled x.py dist, resolving a bug introduced in rust-lang#76549.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 21, 2020
@Dylan-DPC
Rollup merge of rust-lang#76799 - Mark-Simulacrum:fix-cross-compile-d…
a9d2a35 
…ist, r=alexcrichton

Fix cross compiling dist/build invocations

I am uncertain why the first commit is not affecting CI. I suspect it's because we pass --disable-docs on most of our cross-compilation builders. The second commit doesn't affect CI because CI runs x.py dist, not x.py build.

Both commits are standalone; together they should resolve rust-lang#76733. The first commit doesn't really fix that issue but rather just fixes cross-compiled x.py dist, resolving a bug introduced in rust-lang#76549.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 22, 2020
@Dylan-DPC
Rollup merge of rust-lang#76799 - Mark-Simulacrum:fix-cross-compile-d…
a282d1e 
…ist, r=alexcrichton

Fix cross compiling dist/build invocations

I am uncertain why the first commit is not affecting CI. I suspect it's because we pass --disable-docs on most of our cross-compilation builders. The second commit doesn't affect CI because CI runs x.py dist, not x.py build.

Both commits are standalone; together they should resolve rust-lang#76733. The first commit doesn't really fix that issue but rather just fixes cross-compiled x.py dist, resolving a bug introduced in rust-lang#76549.
@bors bors closed this as completed in 44ae0b8 Sep 22, 2020
@glandium glandium mentioned this issue Sep 30, 2020
Open
@jyn514 jyn514 removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-cross Area: Cross compilation C-bug Category: This is a bug. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix cross compiling dist/build invocations Mark-Simulacrum/rust
5 participants
@spastorino @glandium @Mark-Simulacrum @jyn514 @rustbot