"It looks like your C cross-toolchain is incomplete. It is not enough to install a cross-compiler; you also need to install the libraries native to the platform you are compling for."
Is The Embedonomicon dead…? (How healthy is embedded Rust in general?)
bare metal platforms are usually tier 2 or tier 3 rust targets, so they are mostly community supported and receives very few official support from chip manufacturers. (I have only read news from infineon and esppressif, for instance)
in general, it is assumed developers already have at least some experiences of embedded systems in C so they understand the basics of the cross compiling toolchains.
because embedded systems cover a very broad range of targets, the book uses thumbv7m-none-eabi as example because this one is relatively mature in the rust embedded ecosystem and is well supported by the emulator qemu.
I should also point out that, the embedonomicon serves a different purpose than the embedded rust book. if you are new to embedded rust, I suggest you go through the embedded rust book first. below are quotes from the books:
This book caters towards people with either some embedded background or some Rust background, however we believe everybody curious about embedded Rust programming can get something out of this book. For those without any prior knowledge we suggest you read the "Assumptions and Prerequisites" section and catch up on missing knowledge to get more out of the book and improve your reading experience. You can check out the "Other Resources" section to find resources on topics you might want to catch up on.
People that wish to bootstrap bare metal support for an architecture that the ecosystem doesn't yet support (e.g. Cortex-R as of Rust 1.28), or for an architecture that Rust just gained support for (e.g. maybe Xtensa some time in the future).
People that are curious about the unusual implementation of runtime crates like cortex-m-rt, msp430-rt and riscv-rt.
kentborg@tinpan:~/programming/rust-code/embedonomicon-qemu/app$ cargo nm -- target/thumbv7m-none-eabi/debug/deps/app-*.o
warning: `/home/kentborg/programming/rust-code/embedonomicon-qemu/app/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
warning: `/home/kentborg/programming/rust-code/embedonomicon-qemu/app/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
/home/kentborg/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm: error: target/thumbv7m-none-eabi/debug/deps/app-be400d32171c538c.o: No such file or directory
/home/kentborg/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm: error: target/thumbv7m-none-eabi/debug/deps/app-c9909552ee18cf60.o: No such file or directory
app:
kentborg@tinpan:~/programming/rust-code/embedonomicon-qemu/app$
(Except for the cargo 1.38 stuff, but it is two-years later.)
from the error message, the build is successful, but llvm-nm fails. I wonder if it's something to do with the way cargo nm invoking llvm-nm.
just to check if the error is emitted by cargo nm or by llvm-nm, can you also try to run llvm-nm directly, and compare the result of cargo nm? e.g.:
$ cargo nm -- target/thumbv7m-none-eabi/debug/deps/app-*.o
## maybe also check the output of:
$ cargo nm --bin app
$ ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm target/thumbv7m-none-eabi/debug/deps/app-*.o
since cargo-binutils is a third-party package, it's highly likely it's out of sync with the core toolchain, for example, the command line flags might be incompatible with llvm-tools. if that's the case, you can report the issue to cargo-binutils