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 <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 3abc3b97ba ("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 <chris.obbard@oss.qualcomm.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit is contained in:
Chris Obbard
2026-08-31 16:49:57 +01:00
committed by Thomas Petazzoni
parent 7209f55cd2
commit 698535473f

View File

@@ -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 <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