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.

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

Fix cross compilation of LLVM to aarch64 Windows targets #74116

Merged
merged 1 commit into from
Jul 12, 2020

Conversation

arlosi
Copy link
Contributor

@arlosi arlosi commented Jul 6, 2020

When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.

This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, adds the --target option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.

Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 6, 2020
@arlosi
Copy link
Contributor Author

arlosi commented Jul 7, 2020

With this change, it should be possible to compile for aarch64-pc-windows-msvc on CI builders (x86_64 hosts). Is there a way to test this?

cc @pietroalbini @alexcrichton

@Mark-Simulacrum
Copy link
Member

The changes here are somewhat obscure but they seem fine to land, r? @pietroalbini for testing and such though

@alexcrichton
Copy link
Member

For testing this you might be able to run @bors: try on GitHub Actions which are pretty speedy IIRC (assuming there's extra capacity on GitHub Actions). Pietro would know for sure but I think you'd edit this block to be replaced with something Windows-specific (which you'd want to tweak to generate an AArch64 compiler).

That should produce a build and I think even upload it to s3 for later testing, but it should otherwise assist in debugging whether this will work on CI or not.

@pietroalbini
Copy link
Member

With this change, it should be possible to compile for aarch64-pc-windows-msvc on CI builders (x86_64 hosts). Is there a way to test this?

To test this you can create another builder in src/ci/azure-pipelines/try.yml (look in src/ci/azure-pipelines/auto.yml for the skeleton of the Windows job and the other builders), and then we can start a try build.

Unfortunately we don't currently have enough capacity to add a permanent builder though.

@pietroalbini
Copy link
Member

Yay race conditions!

Let's do the try build on Azure Pipelines, we have less capacity issues there.

@arlosi
Copy link
Contributor Author

arlosi commented Jul 7, 2020

Thanks for the help! I added a job to src/ci/azure-pipelines/try.yml.

Not sure if I'm allowed to run it: @bors try

@bors
Copy link
Contributor

bors commented Jul 7, 2020

@arlosi: 🔑 Insufficient privileges: not in try users

@pietroalbini
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Jul 7, 2020

⌛ Trying commit 8d9f968419c92ebdd7eea750408bd9faaa1c4904 with merge 609dab75420c8bdf973843c16a12b4b8109243c7...

@bors
Copy link
Contributor

bors commented Jul 7, 2020

💔 Test failed - checks-azure

@bors bors 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 Jul 7, 2020
@pietroalbini
Copy link
Member

The build failed:

src/ci/scripts/install-mingw.sh can't detect the builder's architecture
please tweak it to recognize the builder named 'dist-aarch64-msvc'

@arlosi
Copy link
Contributor Author

arlosi commented Jul 7, 2020

I added an aarch64 case that uses the x86_64 mingw, which should at least work for the experiment.

@pietroalbini
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Jul 7, 2020

⌛ Trying commit f426c576be1777fd1597dcf1d3a4bf4532fc2731 with merge 4367d63f1de115d200672e0f7352844919562023...

@arlosi
Copy link
Contributor Author

arlosi commented Jul 7, 2020

It failed again because it tried to download a bootstrap aarch64 compiler.

I pushed a new commit to set --build to x86_64, and --host to x86_64,aarch64

Can we try again?

@pietroalbini
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Jul 7, 2020

⌛ Trying commit b0a2c3d81db7239468c973702ef7c2730dfab89c with merge bff4694205ae04a1aea91bb5f39aeb8b0b3d9d4e...

Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 11, 2020
Fix cross compilation of LLVM to aarch64 Windows targets

When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.

This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.

Related issue: rust-lang#72881
Requires LLVM change: rust-lang/llvm-project#67
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 11, 2020
Fix cross compilation of LLVM to aarch64 Windows targets

When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.

This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.

Related issue: rust-lang#72881
Requires LLVM change: rust-lang/llvm-project#67
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 12, 2020
…arth

Rollup of 10 pull requests

Successful merges:

 - rust-lang#72920 (Stabilize `transmute` in constants and statics but not const fn)
 - rust-lang#73715 (debuginfo:  Mangle tuples to be natvis friendly, typedef basic types)
 - rust-lang#74066 (Optimize is_ascii for str and [u8].)
 - rust-lang#74116 (Fix cross compilation of LLVM to aarch64 Windows targets)
 - rust-lang#74167 (linker: illumos ld does not support --eh-frame-hdr)
 - rust-lang#74168 (Add a help to use `in_band_lifetimes` in nightly)
 - rust-lang#74197 (Reword incorrect `self` token suggestion)
 - rust-lang#74213 (Minor refactor for rustc_resolve diagnostics match)
 - rust-lang#74240 (Fix rust-lang#74081 and add the test case from rust-lang#74236)
 - rust-lang#74241 (update miri)

Failed merges:

r? @ghost
@bors bors merged commit 9614238 into rust-lang:master Jul 12, 2020
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants