You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked through the code and came to the conclusion that this crate seems to have an incorrect understanding of the way toolchains work.
1.63.0-thumbv7em-none-eabihf means that our build machine is a thumbv7em-none-eabihf. This is most likely always constant; a machine doesn't spontaneously change its type.
The toolchain then has one or multiple installed targets. This is the compilation target machine, which is what the --target flag should actually control.
The current behavior, if being on an x86_64-unknown-linux-gnu machine and a --target thumbv7em-none-eabihf is specified and we want version 1.63.0, is:
I looked through the code and came to the conclusion that this crate seems to have an incorrect understanding of the way toolchains work.
1.63.0-thumbv7em-none-eabihf
means that our build machine is athumbv7em-none-eabihf
. This is most likely always constant; a machine doesn't spontaneously change its type.--target
flag should actually control.The current behavior, if being on an
x86_64-unknown-linux-gnu
machine and a--target thumbv7em-none-eabihf
is specified and we want version1.63.0
, is:rustup install 1.63.0-thumbv7em-none-eabihf --profile minimal
What should happen instead is:
rustup install 1.63.0 --profile minimal
rustup target add --toolchain 1.63.0 thumbv7em-none-eabihf
Sadly, this makes this crate completely unusable for cross compilation crates (like many embedded crates).
Originally posted by @Finomnis in #587 (comment)
The text was updated successfully, but these errors were encountered: