Skip to content

rust: fix host build on aarch64 darwin#21837

Merged
PolynomialDivision merged 1 commit into
openwrt:masterfrom
jonasjelonek:rust-host-fix-aarch64-darwin-build
Aug 17, 2023
Merged

rust: fix host build on aarch64 darwin#21837
PolynomialDivision merged 1 commit into
openwrt:masterfrom
jonasjelonek:rust-host-fix-aarch64-darwin-build

Conversation

@jonasjelonek

Copy link
Copy Markdown
Member

rust/host failed to compile on macOS running on Apple Silicon M1 Pro because the host target triple is autogenerated to be 'arm64-unknown-linux-'. Rust doesn't have such a target triple, thus the build failes because there are no pre-built artifacts for bootstrapping.

Fix this by setting RUSTC_HOST_ARCH to 'aarch64-apple-darwin' in case our host is HOST_ARCH=arm64 and HOST_OS=darwin.

Maintainer: @lu-zero
Tested: macOS 14 on MacBook M1 Pro Apple Silicon, OpenWrt trunk

Description:

I just tried to compile OpenWrt with a Rust package that I included in my testing package feed. This package depends Rust/host, and it tries to bootstrap Rust environment for this. This bootstrapping failed due to an error in x.py with message:

src/stage0.json doesn't contain a checksum for dist/2023-06-01/rust-std-1.70.0-arm64-unknown-linux-.tar.xz

I did a bit debugging and saw, that the target triple 'arm64-unknown-linux-' isn't properly generated and doesn't come close to a matching Rust target triple. The proper target triple would be 'aarch64-apple-darwin'. Hard-specifying this in rust-values.mk is then working properly, the rust/host build and building the Rust package is working then.

I'm aware of that this fix only fixes build with Apple Silicon macOS. I guess, similar problems could occur on ARM64 based Linux because Rust target triples always use aarch64, but the auto-generated triples use 'uname -m' and end up with 'arm64'. Any thoughts how this could be extended to all aarch64 hosts?

cc @PolynomialDivision

rust/host failed to compile on macOS running on Apple Silicon M1 Pro
because the host target triple is autogenerated to be
'arm64-unknown-linux-'. Rust doesn't have such a target triple, thus the
build failes because there are no pre-built artifacts for bootstrapping.

Fix this by setting RUSTC_HOST_ARCH to 'aarch64-apple-darwin' in case
our host is HOST_ARCH=arm64 and HOST_OS=darwin.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
@lu-zero

lu-zero commented Aug 16, 2023

Copy link
Copy Markdown
Contributor

I'm aware of that this fix only fixes build with Apple Silicon macOS. I guess, similar problems could occur on ARM64 based Linux because Rust target triples always use aarch64, but the auto-generated triples use 'uname -m' and end up with 'arm64'. Any thoughts how this could be extended to all aarch64 hosts?

Linux correctly reports aarch64, I'm surprised the rest works fine on non-linux :)

@lu-zero

lu-zero commented Aug 16, 2023

Copy link
Copy Markdown
Contributor

The patch is fine for me.

@jonasjelonek

Copy link
Copy Markdown
Member Author

I'm aware of that this fix only fixes build with Apple Silicon macOS. I guess, similar problems could occur on ARM64 based Linux because Rust target triples always use aarch64, but the auto-generated triples use 'uname -m' and end up with 'arm64'. Any thoughts how this could be extended to all aarch64 hosts?

Linux correctly reports aarch64, I'm surprised the rest works fine on non-linux :)

Yes, you're right. Could have checked that too ^^. So Linux is safe and it only affects macOS.

@PolynomialDivision

Copy link
Copy Markdown
Member

Nice. Thanks a lot. Please also backport to 23.05. :)

@BKPepe

BKPepe commented Jun 9, 2026

Copy link
Copy Markdown
Member

Returning to this pull request after a few years, as it definitely deserves a follow-up and a proper cross-reference.

Thanks to this PR, I have no issues compiling rust/host on macOS since I'm on aarch64. However, it turns out that a similar tweak is also needed for x86_64 on MacOS, as pointed out in this comment: #29673 (comment)

Since it's all connected, it makes sense to leave these references linked here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants