[Buildroot] [PATCH v2 0/2] package/dtui: fix build failure on targets without 64-bit atomics

[Buildroot] [PATCH v2 0/2] package/dtui: fix build failure on targets without 64-bit atomics

[Christopher Obbard via buildroot]

dtui fails to build on armv5te and 32-bit powerpc: it depends on
tui-textarea which imports std::sync::atomic::AtomicU64 without a
cfg(target_has_atomic = "64") guard. Rustc does not provide 64-bit
atomics on those targets. Upstream seems unmaintained and 0.7.0 is the
latest release, so the package has to be disabled there instead.

v1 open-coded BR2_ARM_CPU_ARMV5 and BR2_powerpc in package/dtui/Config.in.
Following the review feedback, patch 1 adds a hidden
BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64 symbol to
package/rustc/Config.in.host and patch 2 makes dtui depend on it so the
constraint is expressed once and stays correct as rust gains or changes
targets.

Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
---
Changes in v2:
- Add a hidden BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64 symbol to
  package/rustc/Config.in.host, instead of open-coding BR2_ARM_CPU_ARMV5
  and BR2_powerpc in package/dtui/Config.in.
- dtui now depends on that symbol; no functional change from v1, the
  symbol is defined as !BR2_ARM_CPU_ARMV5 && !BR2_powerpc.
- Link to v1: https://patch.msgid.link/20260829-wip-obbardc-package-dtui-fix-armv5-v1-1-1dfdc176385d@oss.qualcomm.com

To: buildroot@buildroot.org
Cc: Christopher Obbard <chris.obbard@oss.qualcomm.com>

---
Christopher Obbard (2):
      package/rustc: add BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64
      package/dtui: require 64-bit atomic support

 package/dtui/Config.in       |  2 ++
 package/rustc/Config.in.host | 16 ++++++++++++++++
 2 files changed, 18 insertions(+)
---
base-commit: cb18f3a74a49a62119857ce1ab712ff4528a1d3d
change-id: 20260822-wip-obbardc-package-dtui-fix-armv5-832655f4860b

Best regards,
--  
Cheers!

Christopher Obbard, MSc BEng (Hons) MIET

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Christopher Obbard via buildroot]

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(+)

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

-- 
2.55.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 2/2] package/dtui: require 64-bit atomic support

[Christopher Obbard via buildroot]

dtui depends on tui-textarea which unconditionally imports AtomicU64 in
src/widget.rs to pack a viewport rectangle into a single atomic word:

  use std::sync::atomic::{AtomicU64, Ordering};
  pub struct Viewport(AtomicU64);

As there is no cfg(target_has_atomic) guard in tui-textarea, its
build fails on any target for which rustc does not provide 64-bit
atomics with:

  Compiling tui-textarea v0.7.0
  error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
    --> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
     |
  10 | use std::sync::atomic::{AtomicU64, Ordering};
     |                         ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
     |
  help: a similar name exists in the module
     |
  10 - use std::sync::atomic::{AtomicU64, Ordering};
  10 + use std::sync::atomic::{AtomicU32, Ordering};

This has been reported to tui-textarea upstream, but unfortunately the
project seems to be unmaintained (issue linked below). A sane workaround
is to disable the package on targets which lack 64-bit atomic support,
which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64
describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
which lack 64-bit atomics, and y everywhere else.

The same problem was hit by package/dust and worked around in commit
3abc3b97bad9 ("package/dust: bump to version 1.1.2") by bumping to a
version in which upstream had added the missing guard. That is not an
option here as tui-textarea 0.7.0 is the latest release.

Note that a runtime test for dtui cannot use the default
infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
disabled; such a test would need an armv7 or aarch64 toolchain instead.

Build tested with utils/test-pkg against:
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE

all three fail with the above error before this change and are skipped
after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
still select and build the package.

Link: https://github.com/rhysd/tui-textarea/issues/66
Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
---
 package/dtui/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/dtui/Config.in b/package/dtui/Config.in
index 65d51df7d5..aee719a63f 100644
--- a/package/dtui/Config.in
+++ b/package/dtui/Config.in
@@ -3,6 +3,8 @@ config BR2_PACKAGE_DTUI
 	depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
 	depends on BR2_USE_MMU # dbus
+	# tui-textarea unconditionally uses AtomicU64
+	depends on BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64
 	select BR2_PACKAGE_DBUS # runtime
 	select BR2_PACKAGE_HOST_RUSTC
 	help

-- 
2.55.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

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
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

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

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 2/2] package/dtui: require 64-bit atomic support

[Romain Naour via buildroot]

Hello Christopher, All,

Le 31/08/2026 à 17:49, Christopher Obbard via buildroot a écrit :
> dtui depends on tui-textarea which unconditionally imports AtomicU64 in
> src/widget.rs to pack a viewport rectangle into a single atomic word:
> 
>   use std::sync::atomic::{AtomicU64, Ordering};
>   pub struct Viewport(AtomicU64);
> 
> As there is no cfg(target_has_atomic) guard in tui-textarea, its
> build fails on any target for which rustc does not provide 64-bit
> atomics with:
> 
>   Compiling tui-textarea v0.7.0
>   error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
>     --> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
>      |
>   10 | use std::sync::atomic::{AtomicU64, Ordering};
>      |                         ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
>      |
>   help: a similar name exists in the module
>      |
>   10 - use std::sync::atomic::{AtomicU64, Ordering};
>   10 + use std::sync::atomic::{AtomicU32, Ordering};
> 
> This has been reported to tui-textarea upstream, but unfortunately the
> project seems to be unmaintained (issue linked below). A sane workaround
> is to disable the package on targets which lack 64-bit atomic support,
> which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64

As discussed in the first patch: BR2_PACKAGE_HOST_RUSTC_ARCH_HAS_ATOMIC_U64

> describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
> powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
> which lack 64-bit atomics, and y everywhere else.
> 
> The same problem was hit by package/dust and worked around in commit
> 3abc3b97bad9 ("package/dust: bump to version 1.1.2") by bumping to a
> version in which upstream had added the missing guard. That is not an
> option here as tui-textarea 0.7.0 is the latest release.
> 
> Note that a runtime test for dtui cannot use the default
> infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
> disabled; such a test would need an armv7 or aarch64 toolchain instead.

We have a few test case that are using an armv7 or aarch64 architecture.
We actually plan to switch the Buildroot testsuite to the aarch64 architecture
by default.

A runtime test for dtui is welcome!

> 
> Build tested with utils/test-pkg against:
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE
> 
> all three fail with the above error before this change and are skipped
> after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
> still select and build the package.
> 
> Link: https://github.com/rhysd/tui-textarea/issues/66
> Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
> Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6

With BR2_PACKAGE_HOST_RUSTC_ARCH_HAS_ATOMIC_U64 updated:

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

Best regards,
Romain


> Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
> ---
>  package/dtui/Config.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/package/dtui/Config.in b/package/dtui/Config.in
> index 65d51df7d5..aee719a63f 100644
> --- a/package/dtui/Config.in
> +++ b/package/dtui/Config.in
> @@ -3,6 +3,8 @@ config BR2_PACKAGE_DTUI
>  	depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
>  	depends on BR2_USE_MMU # dbus
> +	# tui-textarea unconditionally uses AtomicU64
> +	depends on BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64
>  	select BR2_PACKAGE_DBUS # runtime
>  	select BR2_PACKAGE_HOST_RUSTC
>  	help
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

On Mon, Aug 31, 2026 at 04:49:57PM +0100, Christopher Obbard via buildroot wrote:
> 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>

Thanks, applied after renaming the option name, as suggested by
Romain.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 2/2] package/dtui: require 64-bit atomic support

[Thomas Petazzoni via buildroot]

Hello,

On Mon, Aug 31, 2026 at 04:49:58PM +0100, Christopher Obbard via buildroot wrote:
> dtui depends on tui-textarea which unconditionally imports AtomicU64 in
> src/widget.rs to pack a viewport rectangle into a single atomic word:
> 
>   use std::sync::atomic::{AtomicU64, Ordering};
>   pub struct Viewport(AtomicU64);
> 
> As there is no cfg(target_has_atomic) guard in tui-textarea, its
> build fails on any target for which rustc does not provide 64-bit
> atomics with:
> 
>   Compiling tui-textarea v0.7.0
>   error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
>     --> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
>      |
>   10 | use std::sync::atomic::{AtomicU64, Ordering};
>      |                         ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
>      |
>   help: a similar name exists in the module
>      |
>   10 - use std::sync::atomic::{AtomicU64, Ordering};
>   10 + use std::sync::atomic::{AtomicU32, Ordering};
> 
> This has been reported to tui-textarea upstream, but unfortunately the
> project seems to be unmaintained (issue linked below). A sane workaround
> is to disable the package on targets which lack 64-bit atomic support,
> which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_64
> describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
> powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
> which lack 64-bit atomics, and y everywhere else.
> 
> The same problem was hit by package/dust and worked around in commit
> 3abc3b97bad9 ("package/dust: bump to version 1.1.2") by bumping to a
> version in which upstream had added the missing guard. That is not an
> option here as tui-textarea 0.7.0 is the latest release.
> 
> Note that a runtime test for dtui cannot use the default
> infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
> disabled; such a test would need an armv7 or aarch64 toolchain instead.
> 
> Build tested with utils/test-pkg against:
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
> - BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE
> 
> all three fail with the above error before this change and are skipped
> after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
> still select and build the package.
> 
> Link: https://github.com/rhysd/tui-textarea/issues/66
> Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
> Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6
> Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Thanks, applied after:

- Renaming the symbol

- Adding the "depends on" also to the Config.in comment so that the
  comment doesn't appear on CPU architectures where dtui will anyway
  not be available

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot