Can't find crate for `std`

#1

Given the thumbv7em-none-eabihf target installed,

$ rustup target add thumbv7em-none-eabihf

and the following in Cargo.toml,

[dependencies]
heapless = "0.5.1"

[dev-dependencies]
bindgen = "0.52.0"

an empty #![no_std] lib (there's really nothing else!) doesn't compile:

$ cargo build --target=thumbv7em-none-eabihf
   Compiling byteorder v1.3.2
error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not be installed

It compiles fine if I comment out any of these two dependencies, however. If I understand correctly, the issue is that both bindgen and heapless indirectly depend on byteorder of different versions (std vs no-std):

$ cargo tree
└── heapless v0.5.1
    . . .
    └── hash32 v0.1.1
        └── byteorder v1.3.2     <- this is default-features = false
[dev-dependencies]
└── bindgen v0.52.0
    . . .
    ├── rustc-hash v1.0.1
    │   └── byteorder v1.3.2 (*) <- but this includes std
    . . .

The only way I found to resolve this is to vendor the byteorder crate and disable its default feature:

# Cargo.toml

[features]
-default = ["std"]
+default = []
  1. Is there a better way (i.e. without vendoring any crates to me)?
  2. Is this error expected?

Repro repo: https://github.com/withkittens/t-cant-find-crate-for-std-36925

#2

AFAIK the best way would be to ask intermediate crate authors to add the no_std compatibility too (through default feature). Of course, this is not the immediate solution.

1 Like
#3

This is a cargo bug. Features of dev-dependencies shouldn't propagate onto the target's feature, but they do atm. Fixing this is on the roadmap for this year (though it has been planned to be fixed for a couple of years now, and here we are).

3 Likes
#4

Ah, I see:

Unfortunate :pensive: