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

Elaborate on third-party crate compatibility #13

Open
jessebraham opened this issue Nov 29, 2021 · 2 comments
Open

Elaborate on third-party crate compatibility #13

jessebraham opened this issue Nov 29, 2021 · 2 comments

Comments

@jessebraham
Copy link
Member

In general most crates should work when using std, however in practice there seem to be some which rely on functionality which has yet to be implemented.

For example, supposedly the image crate fails with allocation errors during the encoding step (I have not confirmed this personally, but it was reported from the community).

@MabezDev
Copy link
Member

MabezDev commented Dec 2, 2021

This might be quite hard, especially in the case of image because there is no technical limitation as to why image won't work, but expecting to allocate tens of megabytes of RAM on an esp just isn't feasible.

I think the best we could do is mention real technical limitations, i.e rustls won't build on our platform because ring still uses some assembly that hasn't been ported to Xtensa or Riscv (https://github.com/briansmith/ring/blob/8d78cb2c01c964d6da8b522e6657b7f15b0c442d/build.rs#L35-L90).

@jessebraham
Copy link
Member Author

Yeah I realize we can't say "these crates will work and these will not", but I feel we can give some guidelines at the very least. You gave two great examples already, and there are also other factors like "this underlying function is not implemented in esp-idf, so X won't work as a result".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

2 participants