Elaborate on third-party crate compatibility
jessebraham opened this issue · 2 comments
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).
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).
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".