| Message ID | 20260831-wip-obbardc-package-dtui-fix-armv5-v2-1-42eceaa12f55@oss.qualcomm.com |
|---|---|
| State | New |
| Headers | show |
| Series | package/dtui: fix build failure on targets without 64-bit atomics | expand |
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@smile.fr> Best regards, Romain > Signed-off-by: Christopher Obbard <chris.obbard@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 >
Le 02/09/2026 à 23:24, Romain Naour a écrit : > 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@smile.fr> As Thomas noticed, the option should be: config BR2_PACKAGE_HOST_RUSTC_ARCH_HAS_ATOMIC_U64 Best regards, Romain > > Best regards, > Romain > > >> Signed-off-by: Christopher Obbard <chris.obbard@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 >> >
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
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. 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> --- package/rustc/Config.in.host | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)