[Buildroot] [PATCH v2 1/2] package/rustc: add BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64

[Romain Naour]

Hello Christopher, All,

Le 31/08/2026 à 17:49, Christopher Obbard via buildroot a écrit :
> 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 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.

The commit 3abc3b97bad9 ("package/dust: bump to version 1.1.2") was about the
armv7 architecture but it seems to be a mistake since the toolchain used by
default is indeed for armv5
(BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE).

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

Very good commit log!

Reviewed-by: Romain Naour <romain.naour at smile.fr>

Best regards,
Romain


> Signed-off-by: Christopher Obbard <chris.obbard at oss.qualcomm.com>
> ---
>  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..539926144b 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 <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_64
> +	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
>