bootandy/archived-dust
1
0
Fork 0
mirror of https://github.com/bootandy/dust.git synced 2026-06-08 11:29:05 +03:00
Code Issues 21 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #423] Do not use std::sync::atomic::AtomicU64 on platforms which do not support 64-bit atomics #181

New Issue
Closed
opened 2026-06-08 11:26:01 +03:00 by zhus · 5 comments
zhus commented 2026-06-08 11:26:01 +03:00
Owner
Copy Link
Copy Source

Originally created by @NoisyCoil on GitHub (Jul 29, 2024).
Original GitHub issue: https://github.com/bootandy/dust/issues/423

Hi there. While packaging dust for Debian (it landed in unstable yesterday: https://tracker.debian.org/pkg/rust-du-dust), the build failed on armel because AtomicU64 is missing on that platform. I could work around this using portable_atomics, but the underlying issue here is you are using u64s instead of usizes for file sizes and similar stuff even on 32-bit platforms. Could you please fix this? Thank you.

Originally created by @NoisyCoil on GitHub (Jul 29, 2024). Original GitHub issue: https://github.com/bootandy/dust/issues/423 Hi there. While packaging dust for Debian (it landed in unstable yesterday: https://tracker.debian.org/pkg/rust-du-dust), the build failed on armel because `AtomicU64` is missing on that platform. I could work around this using `portable_atomics`, but the underlying issue here is you are using `u64`s instead of `usize`s for file sizes and similar stuff even on 32-bit platforms. Could you please fix this? Thank you.
zhus closed this issue 2026-06-08 11:26:01 +03:00
zhus commented 2026-06-08 11:26:02 +03:00
Author
Owner
Copy Link
Copy Source

@wugeer commented on GitHub (Jul 29, 2024):

If usize is used instead of u64 for file size, then for a 32-bit platform, usize is u32, and the upper limit of the representable file size is 4GB, which obviously does not meet the upper limit of file size.
If you can't compile it on your machine, could you please submit a PR to fix the issue yourself?
Or Could you provide more detailed information to help me reproduce this issue? :(

<!-- gh-comment-id:2256038823 --> @wugeer commented on GitHub (Jul 29, 2024): If usize is used instead of u64 for file size, then for a 32-bit platform, usize is u32, and the upper limit of the representable file size is 4GB, which obviously does not meet the upper limit of file size. If you can't compile it on your machine, could you please submit a PR to fix the issue yourself? Or Could you provide more detailed information to help me reproduce this issue? :(
zhus commented 2026-06-08 11:26:02 +03:00
Author
Owner
Copy Link
Copy Source

@NoisyCoil commented on GitHub (Jul 29, 2024):

Well you're right there, I didn't think about this very obvious shortcoming :-)

The issue as I mentioned before is armel does not have 64-bit atomic unsigned integers: there's AtomicU32 and AtomicUsize but no AtomicU64, so the build fails on that platform since you're using them in src/progress.rs. AtomicU64 only exists when target_has_atomic_load_store = "64" is true (see e.g. https://doc.rust-lang.org/1.80.0/src/core/sync/atomic.rs.html#3141), and armel is not one of those platforms.

The easiest way to reproduce would be to set up a cross-compilation environment for armel and try to build dust. E.g. on debian-like OSes with rustup installed

rustup target add armv5te-unknown-linux-gnueabi
sudo apt install crossbuild-essential-armel

then add

[target.armv5te-unknown-linux-gnueabi]
linker = "arm-linux-gnueabi-gcc"

to .cargo/config.toml and compile with cargo build --targetarmv5te-unknown-linux-gnueabi . The build will fail.

As to possibile ways for fixing this issue, a Debian Rust Team member suggested to use portable-atomic, which has a AtomicU64 for armel too. If you are not opposed to adding one dependency for these platforms alone then sure, I could submit a PR. I want to be clear though that with this change the build succeeds but functionality has not been tested on armel (there are no changes for other platforms).

<!-- gh-comment-id:2256372797 --> @NoisyCoil commented on GitHub (Jul 29, 2024): Well you're right there, I didn't think about this very obvious shortcoming :-) The issue as I mentioned before is armel does not have 64-bit atomic unsigned integers: there's `AtomicU32` and `AtomicUsize` but no `AtomicU64`, so the build fails on that platform since you're using them in `src/progress.rs`. `AtomicU64` only exists when `target_has_atomic_load_store = "64"` is true (see e.g. https://doc.rust-lang.org/1.80.0/src/core/sync/atomic.rs.html#3141), and armel is not one of those platforms. The easiest way to reproduce would be to set up a cross-compilation environment for armel and try to build `dust`. E.g. on debian-like OSes with rustup installed ```shell rustup target add armv5te-unknown-linux-gnueabi sudo apt install crossbuild-essential-armel ``` then add ``` [target.armv5te-unknown-linux-gnueabi] linker = "arm-linux-gnueabi-gcc" ``` to `.cargo/config.toml` and compile with `cargo build --targetarmv5te-unknown-linux-gnueabi` . The build will fail. As to possibile ways for fixing this issue, a Debian Rust Team member suggested to use [portable-atomic](https://crates.io/crates/portable-atomic), which has a `AtomicU64` for armel too. If you are not opposed to adding one dependency for these platforms alone then sure, I could submit a PR. I want to be clear though that with this change the build succeeds but functionality has not been tested on armel (there are no changes for other platforms).
zhus commented 2026-06-08 11:26:02 +03:00
Author
Owner
Copy Link
Copy Source

@wugeer commented on GitHub (Jul 30, 2024):

I think you can submit a PR after sufficient testing on the armel platform and let bootandy review the PR. I hope this can help you. :)

<!-- gh-comment-id:2257276398 --> @wugeer commented on GitHub (Jul 30, 2024): I think you can submit a PR after sufficient testing on the armel platform and let bootandy review the PR. I hope this can help you. :)
zhus commented 2026-06-08 11:26:02 +03:00
Author
Owner
Copy Link
Copy Source

@wugeer commented on GitHub (Aug 6, 2024):

Hi, @NoisyCoil maybe you should turn your commit into a PR so that @bootandy can review the code?
Also I think the comment here is irrelevant and can be removed.
image

<!-- gh-comment-id:2270540104 --> @wugeer commented on GitHub (Aug 6, 2024): Hi, @NoisyCoil maybe you should turn your commit into a PR so that @bootandy can review the code? Also I think the comment here is irrelevant and can be removed. ![image](https://github.com/user-attachments/assets/a2a1a727-5350-406a-afcf-6a7de5c23cd2)
zhus commented 2026-06-08 11:26:02 +03:00
Author
Owner
Copy Link
Copy Source

@NoisyCoil commented on GitHub (Aug 6, 2024):

Hey there. The commit needs some further testing, I'll open a PR when I find the time to do so.

Also I think the comment here is irrelevant and can be removed

ROTFL. That might have been part of the above mentioned testing at some point, I didn't even realize it was there (nor that it would get linked to the main issue). Like, literally ROTFL.

<!-- gh-comment-id:2271599099 --> @NoisyCoil commented on GitHub (Aug 6, 2024): Hey there. The commit needs some further testing, I'll open a PR when I find the time to do so. > Also I think the comment here is irrelevant and can be removed ROTFL. That might have been part of the above mentioned testing at some point, I didn't even realize it was there (nor that it would get linked to the main issue). Like, literally ROTFL.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
 windows help wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zhus (Sergey Zhukov)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bootandy/archived-dust#181
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?