rust 1.80.0 fails to build for aarch64_be-unknown-netbsd

[he32]

I tried to cross-build rust 1.80.0 for the big-endian aarch64 NetBSD target.

I expected to see this happen: I expected (eh, "hoped") that this build would now succeed (1.79.0 didn't)

Instead, this happened: The build bombs out because some SIMD type is not available:

error[E0432]: unresolved import `core::arch::aarch64::float32x2_t`
    --> /usr/pkgsrc/wip/rust180/work/rustc-1.80.0-src/vendor/zerocopy-0.7.34/src/lib.rs:3686:43
     |
3681 | /     macro_rules! simd_arch_mod {
3682 | |         (#[cfg $cfg:tt] $arch:ident, $mod:ident, $($typ:ident),*) => {
3683 | |             #[cfg $cfg]
3684 | |             #[cfg_attr(doc_cfg, doc(cfg $cfg))]
3685 | |             mod $mod {
3686 | |                 use core::arch::$arch::{$($typ),*};
     | |                                           ^^^^ no `float32x2_t` in `core_arch::arch::aarch64`
...    |
3696 | |         };
3697 | |     }
     | |_____- in this expansion of `simd_arch_mod!`
...
3729 | /         simd_arch_mod!(
3730 | |             #[cfg(target_arch = "aarch64")]
3731 | |             aarch64, aarch64, float32x2_t, float32x4_t, float64x1_t, float64x2_t, int8x8_t, int8x8x2_t,
3732 | |             int8x8x3_t, int8x8x4_t, int8x16_t, int8x16x2_t, int8x16x3_t, int8x16x4_t, int16x4_t,
...    |
3737 | |             uint64x1_t, uint64x2_t
3738 | |         );
     | |_________- in this macro invocation

Meta

The build host has 1.80.0 installed, but is using 1.79.0 in the bootstrap process, but that's probably irrelevant here.

rustc --version --verbose:

$ rustc --version --verbose
rustc 1.80.0 (051478957 2024-07-21) (built from a source tarball)
binary: rustc
commit-hash: 051478957371ee0084a7c0913941d2a8c4757bb9
commit-date: 2024-07-21
host: x86_64-unknown-netbsd
release: 1.80.0
LLVM version: 18.1.8
$ 

The details of the failed build can be seen above.

I see one other big-endian aarch64 port, so I'm wondering if I'm alone in observing this issue for big-endian aarch64?

[saethlin]

I want to be helpful, but I'm not sure what a possible resolution of you filing this issue would even be. You are filing an issue about a Tier 3 target (thus we make no guarantees at all about it), on an already-released stable version. We will probably never cut a point release to fix a Tier 3 target.

If you want this and other netbsd targets to build in stable releases, you should be testing that the beta versions build, or upstreaming CI for these targets to us, so that they can become Tier 2. In an ideal world, your users who are downloading your builds for these targets would pitch in so you don't have to do everything :)

[Noratrieb]

does it build on master now?

[he32]

You're of course correct in stating that this is a tier-3 target. In fact, I'm the one who does my best to keeping the various NetBSD targets building (and verifying that the result actually works), and this includes this particular target.

The first question I asked was whether the other big-endian aarch64 target is known to build for 1.80.0. That's basically a "yes/no/don't know" question, and should not be difficult to answer.

Secondly, my build setup is only able to handle "tarballs", i.e. official distributions. In fact, I am unsure where the "how to build" instructions are for building a "nightly" version of the rust compiler.

Thirdly, this build failure occurs when cross-building, so should be reproducible "anywhere", and I have a vague suspicion that it affects that other big-endian aarch64 target as well.

Please do note, I do all this on my own spare time, so I appreciate any helpful hints which might point me in the right direction.

I've asked a bit around and while the neon extension in aarch64 is supposedly also available in big-endian mode, code using the neon SIMD extnsions all too often isn't carefully enough written to also actually work in big-endian mode. I guess what I'm asking is whether the rust compiler has been written with that sufficient careful attention, or whether it might be a more productive route to follow to abandon trying to use neon SIMD on big-endian aarch64.

[bjorn3]

Secondly, my build setup is only able to handle "tarballs", i.e. official distributions. In fact, I am unsure where the "how to build" instructions are for building a "nightly" version of the rust compiler.

We provide source tarballs for every beta and nightly release too. For example https://static.rust-lang.org/dist/2024-08-25/rustc-nightly-src.tar.gz for nightly-2024-08-25 or https://static.rust-lang.org/dist/rustc-beta-src.tar.xz for the latest beta. For building manually see https://github.com/rust-lang/rust/blob/master/INSTALL.md

As for how to fix this issue, you will need to change https://github.com/google/zerocopy/ Possibly by changing the #[cfg(target_arch = "aarch64")] mentioned in the error message to #[cfg(all(target_arch = "aarch64", target_endian = "little"))]. We don't expose vector types on big-endian aarch64 because they are broken there: rust-lang/stdarch#1484

[he32]

Thanks for the hints! So far I've grown patches to zerocopy-0.7.34 and the next hurdle is memchr-2.7.2 for basically the same reason, and I'm not quite done yet.

[he32]

So, there, I have a cross-built version for big-endian aarch64. I had to touch up the following files:

vendor/memchr-2.7.2/src/vector.rs
vendor/memchr-2.7.2/src/arch/aarch64/memchr.rs
vendor/memchr-2.7.2/src/arch/aarch64/mod.rs
vendor/memchr-2.7.2/src/memmem/searcher.rs
vendor/memchr-2.7.2/src/memchr.rs
vendor/zerocopy-0.7.34/src/lib.rs
vendor/zerocopy-0.7.32/src/lib.rs
src/tools/rust-analyzer/lib/line-index/src/lib.rs
vendor/bytecount-0.6.8/src/lib.rs

Well, the two arch-specific aarch64 files in memchr are possibly not required. We'll see.

[he32]

OK, the various pointers given led me to a working rust 1.80.1 on aarch64eb on NetBSD.
Thanks! There's more to follow up here for me, I'll take note of that on my TODO list.

[Noratrieb]

@he32 is there a reason to attempt to send patches to everyone instead of fixing the intrinsics in stdarch? Amanieu has laid out in the stdarch issue how that could be done, that seems like both less effort and making it easier and nicer for everyone

[he32]

@he32 is there a reason to attempt to send patches to everyone instead of fixing the intrinsics in stdarch?

You mean, above the fact that fixing the intrinsics in stdarch and probably also battling with LLVM would be waay above and beoynd both my abilities, my available time, my sense of responsibility, and my energy to push such a change through?

Amanieu has laid out in the stdarch issue how that could be done, that seems like both less effort and making it easier and nicer for everyone

I guess I'll take a look at what that is about, and assess whether my gut reaction above is accurate or not.

...

On reading through the stdarch issue, I see that my initial hunch is approximately accurate. It may not be a battle with LLVM, but I know too little rust to write own acceptable code to tackle this issue. In comparison, modifying pre-processor conditionals is easy-peasy.