unresolved import `std::sync::atomic::AtomicUsize` in no_std environment

[mutantbob]

I am trying to port an app to an atmega2560 (avr architecture).

The embedded-svc crate uses log with this clause

[dependencies.log]
version = "0.4"
default-features = false

This should make the log crate no_std

lib.rs:321: #![cfg_attr(all(not(feature = "std"), not(test)), no_std)]

However, I still get the following compile error:

error[E0432]: unresolved import `std::sync::atomic::AtomicUsize`
   --> /home/thoth/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.17/src/lib.rs:348:25
    |
348 | use std::sync::atomic::{AtomicUsize, Ordering};
    |                         ^^^^^^^^^^^ no `AtomicUsize` in `sync::atomic`

Shouldn't a no_std build avoid pulling things from std? Other crates use the atomic-polyfill crate in this situation. Maybe switching to core::sync would work, but I'm not sure which version of rust stabilized that.

[Thomasdezeeuw]

@mutantbob you might have to add the target to the build script: https://github.com/rust-lang/log/blob/63d7747386eafdf28cad189c6acdef423f0d4eb4/build.rs#L24-L42

IIRC if it's added their it should build, build you'll only have access to log::set_logger_racy, which is not thread safe. But I assume that's not a problem for the atmega, or does it have threads?

[ryankurte]

i think there's an underlying issue here expecting TARGET to be a viable tuple when this could also be a json file for a more specific target.

it seems like the best way to solve this would be to attempt to ask rustc for the Target object (via rustc -Z unstable-options --print target-spec-json so RUST_TARGET_PATH etc. are considered), perhaps with a fallback to this manual approach in case of failure?

[KodrAus]

Ideally we'd use target_has_atomic_load_store for this, but it's still unstable. In the meantime, adding new platforms as they appear to that build script is something we're happy to do.

[ryankurte]

Ideally we'd use https://github.com/rust-lang/rust/issues/94039 for this

ahh how nice that'll be! fyi there's similar logic in heapless that might serve as a point of reference for some missing options.

have y'all considered gating the atomics with a feature and inverting this logic so it is still possible to disable em if reqired?

introducing such would be breaking for anyone using --no-default-features though one could automatically -enable- cas based on a list of supported platforms rather than -disabling- on unsupported to mitigate this (and unrecognised platforms could still opt in).

[KodrAus]

I think we should be able to close this one once #552 lands, right?

[MarkGhebrial]

Yes, I've confirmed that #552 resolves this

[Thomasdezeeuw]

Closing as resolved based on https://github.com/rust-lang/log/issues/526#issuecomment-1515639902.