std-template not compiling/core crate not found

[RoyalFoxy]

Bug description

I generated a fresh esp-idf template project with the command cargo generate esp-rs/esp-idf-template cargo and it doesn't build. I get this error

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --cfg espidf_time64 --target xtensa-esp32-espidf --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit status: 1)
  --- stderr
  error: could not create LLVM TargetMachine for triple: xtensa-none-elf: No available targets are compatible with triple "xtensa-none-unknown-elf"

I have an existing project that "compiles" but gets stuck on the core crate as it apparently does not exist.

error[E0463]: can't find crate for `core`
  |
  = note: the `riscv32imac-esp-espidf` target may not be installed
  = help: consider downloading the target with `rustup target add riscv32imac-esp-espidf`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `byteorder` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

As a side note, it worked perfectly fine before for months and suddenly it stopped compiling and I got the second error. I tried creating new template projects and I got the same error at first but then I went through the entire book again to install everything from scratch and checked the links in the bug issue template. Nothing seemed to work.

• Would you like to work on a fix? [y/n]
  No as I don't know what's causing it

To Reproduce

Steps to reproduce the behavior:

Likely not reproducible but I'll try :)

1. Go through the esp book and install everything (std and no-std requirements)
2. Install everything from https://github.com/esp-rs/esp-idf-template#prerequisites
3. Create a new project with cargo generate esp-rs/esp-idf-template cargo
4. Try to build with cargo build
5. See a failed build (maybe??)

Creating a project from the master branch also doesn't build for me

Have it build the template like before

• OS: macOS 15.0 Beta (24A5331b)
• How did you install the environment: espup 0.12.2

Additional context

I tried installing everything like 10 times already so that may've bricked something... I also did work with an esp-idf project (not rust) one like exactly 1 year ago~ and it has worked afterwards regardless of it and just now broke but maybe it has to do something with it

[RoyalFoxy]

I found out more information about this issue. If I create a template for the c6 processor it doesn't find the core crate but for the default esp32 processor rustc fails to compile as llvm doesn't find the triplet

[RoyalFoxy]

So trying to compile for the c6 processor with the master branch of the template or the 5.1 version doesn't work either and spits out the same "crate core not found" error

[RoyalFoxy]

It works with dev containers but is a lot slower as I'm on an m2 processor so the container needs to be emulated 🫠
But at least it works for now. Would still like some help for my issue

[Vollbrecht]

what is the output of rustup show ?

[Vollbrecht]

In general if you are not specifying a toolchain manually, we always use the toolchain that is specified inside the rust-toolchain.toml that is inside your project root dir.

[ivmarkov]

@RoyalFoxy

I have an existing project that "compiles" but gets stuck on the core crate as it apparently does not exist.

Crates core, std, panic_abort and so on are built with your project every time you do cargo build. They are not available "per-se", because all ESP IDF targets are Tier 3.

For this to happen, you must have a properly configured .cargo/config.toml in your binary crate root (look there for a TOML section named [unstable]).
esp-idf-template does that for you, but if you have another .cargo/config.toml in a parent or grand-parent directory of your binary crate, it will mess up things.

Further, you should either use rust "nightly" (rustup default nightly), or rust "esp" (look at the "espup" documentation in this GH project README). What toolchain you are currently using can be seen with rustup show.

[ivmarkov]

I also suggest you read the README of this project carefully, top to bottom and make sure you applied have all steps, and nothing more.

For example, don't try to be adventurous by installing and activating ESP-IDF yourself. This is possible, but is an advanced configuration better avoided initially.

[RoyalFoxy]

@Vollbrecht
This is the output

Default host: aarch64-apple-darwin
rustup home:  /Users/royalfoxy/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin (default)
nightly-2021-01-07-aarch64-apple-darwin
nightly-2022-08-08-aarch64-apple-darwin
nightly-2023-08-08-aarch64-apple-darwin
nightly-2024-03-22-aarch64-apple-darwin
nightly-2024-04-11-aarch64-apple-darwin
nightly-2024-04-17-aarch64-apple-darwin
nightly-aarch64-apple-darwin
1.61.0-aarch64-apple-darwin
esp

installed targets for active toolchain
--------------------------------------

aarch64-apple-darwin
riscv32imac-unknown-none-elf
riscv32imafc-unknown-none-elf
riscv32imc-unknown-none-elf

active toolchain
----------------

nightly-aarch64-apple-darwin (overridden by '/Users/royalfoxy/files/school/programming/m245/m5-nano-c6/rust-toolchain.toml')
rustc 1.83.0-nightly (18b1161ec 2024-10-02)

and I didn't specify any toolchain myself and relied on the template itself to work as it did in the past

[RoyalFoxy]

@ivmarkov I'm aware they arent shipped pre compiled, by not found/available I meant that the rust compiler literally said "can't find crate for core". I also didn't alter my config.toml besides the baudrate and the CRATE_CC_NO_DEFAULTS if Im not mistaken.

[build]
target = "riscv32imac-esp-espidf"

[target.riscv32imac-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor --baud 460800"
rustflags = [ "--cfg",  "espidf_time64"]

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32c6"
ESP_IDF_VERSION = "v5.2.2"


CRATE_CC_NO_DEFAULTS = "1"

I also did use espup like I did in the past and it always worked until it magically didn't anymore. I updated nothing regarding espup and just opened the project and tried to flash my esp32-c6 but then it complained it can't find the crate core all of the sudden which it didn't the week prior.

Switching the toolchain nightly also changed nothing sadly

I also didn't install esp-idf myself for development with rust, I actually did so with the python scripts provided by their devs and had to do so as I was programming in a c++ codebase for a bit but as I stated, that never effected anything for over a year so that shouldn't be an issue.

I already read through all the prerequisites and how to use this template with cargo generate and tried it multiple times but never could get it to build

[ivmarkov]

OK but apparently you have something miscondigured on _your machine, or else how would you explain that it does not even attempt to compile core? "Can't find core" means it does not even attempt to build it, and is expecting that it is already pre-built for the target.

Do you have any RUSTFLAGS env variable defined?

[ivmarkov]

I found out more information about this issue. If I create a template for the c6 processor it doesn't find the core crate but for the default esp32 processor rustc fails to compile as llvm doesn't find the triplet

You have this:

nightly-aarch64-apple-darwin (overridden by '/Users/royalfoxy/files/school/programming/m245/m5-nano-c6/rust-toolchain.toml')
rustc 1.83.0-nightly (18b1161ec 2024-10-02)

In other words, you would be using nightly for this project, no matter what. The README is pretty clear, that you do need the esp rust toolchain instead for all xtensa targets, as they are not upstreamed yet in llvm.

[RoyalFoxy]

But that's literally the template that specifies nightly, I didn't touch the rust-toolchain.toml file.

[RoyalFoxy]

I tried changing the channel in the toolchain file to esp instead of nightly but same issue. I'm pretty confused what changed cause as I mentioned it did work just fine roughly 2 weeks ago and around 1 week ago it just didn't compile anymore and I mean it when I say I didn't touch anything in that project or even touched rust for that week or updated any of the programs used with rust development.

[RoyalFoxy]

how do I like uninstall everything related to esp rust development so I can start from new installing all the dependencies and stuff and basically start from a clean slate? Maybe that's like my best option cause I through the esp rs book so many times and I just generated the template and it doesn't work and it used to always work

[ivmarkov]

OK but apparently you have something miscondigured on _your machine, or else how would you explain that it does not even attempt to compile core? "Can't find core" means it does not even attempt to build it, and is expecting that it is already pre-built for the target.

Do you have any RUSTFLAGS env variable defined?

Did you read this?

[RoyalFoxy]

Not in my fish config and the only rust flag I can think of is the one in the .cargo config

rustflags = [ "--cfg",  "espidf_time64"]

I'm unsure if I added that, I can't remember if it was a different project I had to add a rustflag like that

[RoyalFoxy]

Just checked, that's in the template too

[RoyalFoxy]

Ohh and ye the RUSTFLAGS variable in the terminal is not set, sorry I didnt add that

[RoyalFoxy]

Is there any other way I can like show all the rust flags that the compiler would use in a given directory?

[ivmarkov]

Is there any other way I can like show all the rust flags that the compiler would use in a given directory?

cargo build --verbose?

[RoyalFoxy]

Sorry I'm still learning

rustc 
--crate-name nb 
--edition=2018 /Users/royalfoxy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nb-1.1.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat 
--diagnostic-width=162 
--crate-type lib 
--emit=dep-info,metadata,link -C opt-level=z -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=on 
--check-cfg 'cfg(docsrs)' 
--check-cfg 'cfg(feature, values("defmt-0-3"))' -C metadata=2b0692c3af470e51 -C extra-filename=-2b0692c3af470e51 
--out-dir /Users/royalfoxy/files/school/programming/m245/testing/target/riscv32imac-esp-espidf/debug/deps 
--target riscv32imac-esp-espidf -C linker=ldproxy -L dependency=/Users/royalfoxy/files/school/programming/m245/testing/target/riscv32imac-esp-espidf/debug/deps -L dependency=/Users/royalfoxy/files/school/programming/m245/testing/target/debug/deps 
--cap-lints allow 
--cfg espidf_time64

[RoyalFoxy]

Hello. This issue is still present for me, I cannot build std projects on my hardware natively and need to use dev containers which massively slows down the build.

I Have worked through the https://docs.esp-rs.org/book/ several times at this point and tried to also go backwards and do all of the "uninstalling" commands instead to try and remove everything that was installed but without success.

Is there a way I can sort of reset everything so I can start fresh? It really bugs me personally that I have to wait multiple minutes each time I change something just for the container to compile everything again.

[Vollbrecht]

If you are using the riscv toolchain, you only need a official rust nightly compiler. As explained before, it will build the std library etc from scratch via the unstable feature Zbuild_std that is always set in a new project configured via the esp-idf-template. As long as your environment does not provide anything else, the complete installation of the esp-idf toolchain (needed to build the underlying C sdk project) and all the specific stuff is automatically project independent installed inside your .embuild directory.

The project itself never sets anything permanently, with respect to env variables or other stuff that could influence default behavior. So in short have the latest rustc nightly compiler installed and generate a new project from the template.

Since that is fully self contained it should compile. If not than you need to provide information on what happens exactly.

[RoyalFoxy]

Thanks for your response, I'm glad you want to help me <3

Here is some things that might help :/

I'm not using the riscv toolchain, anymore at least, as I migrated the project to the esp32 processor which uses xtensa.

I installed espup as described here, executed the command . $HOME/export-esp.sh and installed the other dependencies described here as well.

I've tested this on a macos virtual machine on my laptop that can't build and it could build inside the vm, same macos version, same rust version, same everything.

I have removed the esp-idf folder I used to have as I had previous projects written in c++ using it (even tho it didn't harm the build process in the past I just removed it as I also didn't need it anymore).

I have a rust-toolchain.toml file that has been created with the template for the esp32 and the contents are as follows

[toolchain]
channel = "esp"

The .cargo/config.toml file looks like this

[build]
target = "xtensa-esp32-espidf"

[target.xtensa-esp32-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor" # Select this runner for espflash v3.x.x
rustflags = [ "--cfg",  "espidf_time64"] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.1.4"

# Workaround for https://github.com/esp-rs/esp-idf-template/issues/174 
CRATE_CC_NO_DEFAULTS = "1"

There exists an .embuild folder.

Trying to run rustup run esp cargo build to make absolutely sure the esp toolchain is used yields the same error

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --cfg espidf_time64 --target xtensa-esp32-espidf --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit status: 1)
  --- stderr
  error: could not create LLVM TargetMachine for triple: xtensa-none-elf: No available targets are compatible with triple "xtensa-unknown-none-elf"

Running rustc --print=target-list yields all the targets and at the end it has the following

...
xtensa-esp32-espidf
xtensa-esp32-none-elf
xtensa-esp32s2-espidf
xtensa-esp32s2-none-elf
xtensa-esp32s3-espidf
xtensa-esp32s3-none-elf

From my rather limited understanding of llvm targets the target xtensa-esp32-none-elf would seem to match the xtensa-unknown-none-elf and maybe that somehow failed to sync?

The code of the project is irrelevant as it also doesn't build with the stock template after generating it for the esp32.

Are there any executables or env variables that can cause this to not compile that may be left over from a previous install or got corrupted in any way? Maybe hidden installation folders that aren't located in the project or home directory and that don't get removed?