From 698535473f7340402d3c36bc1eb66237c63ef083 Mon Sep 17 00:00:00 2001 From: Chris Obbard Date: Mon, 31 Aug 2026 16:49:57 +0100 Subject: [PATCH] package/rustc: add BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_U64 Rust does not provide 64-bit atomics on every target Buildroot can generate. rustc sets max_atomic_width = 32 for three of the 25 targets listed in RUST_TARGETS in utils/update-rust, so core::sync::atomic::AtomicU64 and AtomicI64 simply do not exist there: $ rustc --print cfg --target | grep target_has_atomic armv5te-unknown-linux-gnueabi "16" "32" "8" "ptr" armv5te-unknown-linux-musleabi "16" "32" "8" "ptr" powerpc-unknown-linux-gnu "16" "32" "8" "ptr" Every other supported target, including armv6, armv7, aarch64, all the x86 variants, riscv64, s390x, sparc64 and both 64-bit powerpcs, has them, e.g.: arm-unknown-linux-gnueabi "16" "32" "64" "8" "ptr" armv7-unknown-linux-gnueabihf "16" "32" "64" "8" "ptr" A crate that uses 64-bit atomics without a cfg(target_has_atomic = "64") guard therefore fails to build on those three targets with: error[E0432]: unresolved import `std::sync::atomic::AtomicU64` | | atomic::{AtomicU64, AtomicU8, AtomicUsize, Ordering}, | ^^^^^^^^^ no `AtomicU64` in `sync::atomic` This has been hit at least twice already: by package/dust, worked around in commit 3abc3b97bad9 ("package/dust: bump to version 1.1.2") by moving to a release in which upstream had added the guard and by package/dtui, which has no such release available and had to open-code the affected architectures instead. It is likely to keep recurring: infra.basetest.BASIC_TOOLCHAIN_CONFIG builds with BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, so every runtime test that does not override the toolchain compiles for armv5te, one of the three affected targets. That is exactly how the two failures above were found. Add a hidden symbol so packages can express this constraint once, rather than each open-coding BR2_ARM_CPU_ARMV5 and BR2_powerpc and needing to update whenever rust gains or changes a target. Note that armv5te and 32-bit powerpc are only supported by rust for glibc and musl, so the uclibc variants of those architectures are already excluded by BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS. Signed-off-by: Christopher Obbard Reviewed-by: Romain Naour Signed-off-by: Thomas Petazzoni --- package/rustc/Config.in.host | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/package/rustc/Config.in.host b/package/rustc/Config.in.host index 9cd912fc74..6130b73921 100644 --- a/package/rustc/Config.in.host +++ b/package/rustc/Config.in.host @@ -112,6 +112,22 @@ config BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS depends on BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_USES_MUSL depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS +# Not all the targets above provide 64-bit atomics: rustc sets +# max_atomic_width = 32 for armv5te-unknown-linux-{gnu,musl}eabi and for +# powerpc-unknown-linux-gnu, so core::sync::atomic::{AtomicU64,AtomicI64} +# do not exist there. This can be checked with: +# rustc --print cfg --target | grep target_has_atomic +# Target rust packages whose crates use 64-bit atomics unconditionally, +# i.e. without a cfg(target_has_atomic = "64") guard, should depend on +# this option. +config BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_U64 + bool + # Excludes armv5te-unknown-linux-{gnu,musl}eabi and + # powerpc-unknown-linux-gnu. BR2_powerpc is 32-bit only: + # BR2_powerpc64 and BR2_powerpc64le are separate symbols, both + # selecting BR2_ARCH_IS_64, and are not affected. + default y if !BR2_ARM_CPU_ARMV5 && !BR2_powerpc + config BR2_PACKAGE_HOST_RUSTC_ARCH string default "armv5te" if BR2_ARM_CPU_ARMV5