Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no_std depends on bincode #35

Closed
aep opened this issue Aug 21, 2018 · 11 comments
Closed

no_std depends on bincode #35

aep opened this issue Aug 21, 2018 · 11 comments

Comments

@aep
Copy link

@aep aep commented Aug 21, 2018

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

@aep
Copy link
Author

@aep aep commented Aug 21, 2018

@jamesmunns
Copy link
Contributor

@jamesmunns jamesmunns commented Aug 21, 2018

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

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

@aep aep changed the title no_std depends on rand no_std depends on bincode Aug 21, 2018
@jamesmunns
Copy link
Contributor

@jamesmunns jamesmunns commented Aug 21, 2018

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
Copy link
Member

@isislovecruft isislovecruft commented Sep 6, 2018

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
Copy link
Member

@isislovecruft isislovecruft commented Dec 24, 2018

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
Copy link
Author

@aep aep commented Dec 31, 2018

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

@tarcieri
Copy link
Contributor

@tarcieri tarcieri commented Jan 1, 2019

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

@nickray
Copy link
Contributor

@nickray nickray commented Jan 27, 2019

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 :)

@isislovecruft
Copy link
Member

@isislovecruft isislovecruft commented Jul 14, 2020

Hi @aep! Are you still hitting issues with no_std? If not, please feel free to reopen this issue (I'm trying to close out old bug reports).

@aep
Copy link
Author

@aep aep commented Jul 14, 2020

We don't use rust anymore sorry. Closing sounds good. Don't think many people care about nostd anyway. :)

@nickray
Copy link
Contributor

@nickray nickray commented Jul 16, 2020

We don't use rust anymore sorry. Closing sounds good. Don't think many people care about nostd anyway. :)

Hey! 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants