Building no_std fails, even without any features

[jhwgh1968]

The README implies that a #![no_std] build should work if all the default features are disabled. There is even a build-nostd.sh in the repository.

However, I notice that script does not actually remove the standard library from the dependency tree. When I actually do that -- by compiling for an embedded target without a libstd -- it fails:

$ cargo build --no-default-features --target armv7a-none-eabi --jobs 1
   Compiling log v0.4.11
   Compiling bitflags v1.2.1
   Compiling cfg-if v0.1.10
error[E0463]: can't find crate for `std`
  |
  = note: the `armv7a-none-eabi` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `log`

To learn more, run the command again with --verbose.

It seems that even if this crate is #![no_std], its log crate dependency is not.

This crate seems necessary for a ton of debug!(...) prints and other things scattered throughout the code. It was added in da76625, way back in 2017 (!) and looks rather difficult to remove.

I can hack around this myself, for my own purposes. But is there some possible upstream solution? If so, I would happily open a PR to add a CI job which builds and runs a really-no-kidding #![no_std] binary to prevent this from happening again.

[jhwgh1968]

Hmm, that is interesting.

The log crate itself suggests that it should be #![no-std]
https://github.com/rust-lang/log/blob/078e68fa1e27d3dd66ee524e0ef646cfb434c6f9/src/lib.rs#L273

#![cfg_attr(all(not(feature = "std"), not(test)), no_std)]

However, it seems that the argument --cfg feature="std" is passed to rustc when building the log crate, even when I set --no-default-features. Very strange.

[rafalh]

You should be able to remove all debug stuff from a binary by using log crate compile time filters: https://docs.rs/log/0.4.11/log/#compile-time-filters
As for building failure if its the log crate causing problems maybe you should create an issue in that crate repo. I was trying some no_std builds in the past with a MIPS target and it was working but I don't remember details. Maybe log crate regressed since then. I must say I don't really use no_std regularly so there may be some issues and I will be happy to accept contributions improving this library for such use-case.

[jhwgh1968]

Well, this is interesting.

Apparently it's not your fault, and it's not the log crate's fault, but it's because of the log crate pulled in as a dev dependency that requires the standard library.

I will close this, and consider a CI improvement PR in the future.