no_std depends on bincode

[aep]

https://gist.github.com/jamesmunns/8d4de492b1b6eb56f078a1fe975aa758

[aep]

cc @jamesmunns

[jamesmunns]

Context: We are considering trying to use ed25519 in a microcontroller context.

It looks like the dependency on bincode has a hard std dependency: TyOverby/bincode#189

[jamesmunns]

It also seems to complain about byteorder, but from a first glance I can't understand why (you specify no default features):

james@archmac13r2 ➜  ed25519-dalek git:(master) cargo build -j1 --no-default-features --target thumbv7em-none-eabihf
   Compiling proc-macro2 v0.4.13
   Compiling typenum v1.10.0                                                                     
   Compiling cc v1.0.18                                                                          
   Compiling unicode-xid v0.1.0                                                                  
   Compiling rand_core v0.2.1                                                                    
   Compiling byteorder v1.2.4                                                                    
   Compiling subtle v0.7.0                                                                       
   Compiling failure_derive v0.1.2                                                               
   Compiling cfg-if v0.1.5                                                                       
   Compiling rustc-demangle v0.1.9                                                               
error[E0463]: can't find crate for `std`                               ] 11/41: byteorder        
  |
  = note: the `thumbv7em-none-eabihf` 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 `byteorder`.  

[isislovecruft]

Hi @aep and @jamesmunns! Thanks for reporting this. It appears to be a bug in curve25519-dalek, which this crate depends upon. curve25519-dalek depends upon byteorder for both buildtime and runtime, and I was able to compile byteorder with cargo build -j1 --no-default-features --target thumbv7em-none-eabihf. I think it may have something to do with curve25519-dalek's two-stage build process where cargo isn't passing either the correct flags or targets to both build stages? (cc/ @hdevalence)

[isislovecruft]

Hi @aep and @jamesmunns! We think we've experienced curve25519-dalek's two-stage build.rs script causing cross compilation issues elsewhere, and we've made a ticket (dalek-cryptography/curve25519-dalek#217) for replacing it with something friendlier. I'm guessing you're still hitting this issue?

[aep]

@isislovecruft thanks. Yeah, still doesn't compile for no-std.

[tarcieri]

This is an interesting looking tool for verifying no_std-compatibility https://github.com/hobofan/cargo-nono

[nickray]

If you remove the dev-dependencies which aren't no_std-compatible from dalek-cryptography/curve25519-dalek#187, and add default-features = false to rand here, it's possible to compile for thumb targets.
I'd wager that due to rust-lang/cargo#4866 on mainstream/desktop targets no_std builds aren't actually no_std :)