Add aarch64-unknown-linux-musl target

[tjkirch]

This adds support for the aarch64-unknown-linux-musl target in the build and CI systems.

This addresses half of issue #42520.

The new file aarch64_unknown_linux_musl.rs is a copy of aarch64_unknown_linux_gnu.rs with "gnu" replaced by "musl", and the added logic in build-arm-musl.sh is similarly a near-copy of the arches around it, so overall the changes were straightforward.

Testing:

$ sudo ./src/ci/docker/run.sh cross
...
Dist std stage2 (x86_64-unknown-linux-gnu -> aarch64-unknown-linux-musl)
Building stage2 test artifacts (x86_64-unknown-linux-gnu -> aarch64-unknown-linux-musl)
   Compiling getopts v0.2.14
   Compiling term v0.0.0 (file:///checkout/src/libterm)
   Compiling test v0.0.0 (file:///checkout/src/libtest)
    Finished release [optimized] target(s) in 16.91 secs
Copying stage2 test from stage2 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-musl)
...
Build completed successfully in 0:55:22

$ rustup toolchain link local obj/build/x86_64-unknown-linux-gnu/stage2
$ rustup default local

After setting the local toolchain as default, and adding this in ~/.cargo/config:

[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-musl-gcc"

...then the toolchain was able to build a working ripgrep as a test:

$ readelf -a target/aarch64-unknown-linux-musl/debug/rg | grep -i interpreter
$ readelf -a target/aarch64-unknown-linux-musl/debug/rg | grep NEEDED
$ file target/aarch64-unknown-linux-musl/debug/rg
target/aarch64-unknown-linux-musl/debug/rg: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=be11036b0988fac5dccc9f6487eb780b05186582, not stripped

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[tjkirch]

As a note, testing was impacted by #43982 and the workaround mentioned there of removing --enable-extended was sufficient.

[Mark-Simulacrum]

cc @aturon @alexcrichton @rust-lang/infra

What is our current policy on adding new targets?

[alexcrichton]

Thanks for the PR @tjkirch! @Mark-Simulacrum this falls in the category of "small targets" in the sense that it takes very little cost for us to build and store these artifacts. Along those lines, should be fine and easy to add!

@tjkirch for many of our other musl targets, however, they default to static linkage by default on musl. I wonder, would it be possible to do the same here as well? I think that'd necessitate basically just copying over some settings from files like arm_unknown_linux_musleabi.rs instead.

And finally, would you be willing to help out, after landing this, getting CI for libc up and running for this target? There's probably at least one incorrect defintion for aarch64-musl, and it'd be good to weed them out early!

[tjkirch]

@alexcrichton - @bcressey and I are happy to do more to help. With a few pointers I'm sure we can get it.

Regarding static linkage: I'm guessing the relevant difference between arm_unknown_linux_musleabi.rs and the new aarch64_unknown_linux_musl.rs is the "base" it's using, and that switching to super::linux_musl_base would be the right thing. Now that I see what's in the musl base, that makes sense. Does that sound right?

Regarding getting CI running for libc, sure! But I'm even more clueless there :) I'm guessing there's a cross compilation environment that needs to be set up for the builders, and we have experience with that in our environment, but I'm not sure where to look for the official Rust builds. Happy to help once we have a better idea here.

Thanks!

[alexcrichton]

@tjkirch yeah switching the base sounds right to me!

I can also help out once this has landed to get libc up and running, it hopefully shouldn't be too different than this!

If you've got a rustc with the aarch64-unknown-linux-musl target locally, you can explore the CI of libc as well through the various docker images. For example this is what x86_64-musl looks like and this would probably also share some similarities with aarch64-unknown-linux-gnu to run tests.

If you're curious to give it a try, all you need to do is make sure that rustc with the aarch64 target is in your PATH and then run ./ci/run-docker.sh aarch64-unknown-linux-musl in the libc repo, and it should guide you through the rest.

[tjkirch]

@alexcrichton - I've updated the commit to include the linux_musl_base change, tested, and updated my initial description to show that it now builds statically without linking to libgcc. Still looking into the libc changes. :)

[alexcrichton]

@bors: r+

Ok! We can land this in the meantime

[bors]

📌 Commit f94bd36 has been approved by alexcrichton

[bors]

⌛ Testing commit f94bd36 with merge e7473a8...

[bors]

💔 Test failed - status-travis

[tjkirch]

Hmm - seems to have been a segfault in lldb? This one test failed under i686-apple-darwin: "[debuginfo-lldb] debuginfo/destructured-for-loop-variable.rs"

Have you seen this before @alexcrichton? Could it be related to this change?

[alexcrichton]

@bors: retry

Nah that looks like a spurious test failure, but let's try again to confirm.

[bors]

⌛ Testing commit f94bd36 with merge 9cb90f4...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 9cb90f4 to master...