esp-idf-sys-0.35.0: error[E0308]: mismatched types #343
Comments
|
the error occurs also with no preinstalled ESP-IDF and the build script downloads the ESP-IDF repo and installs everything automatically. |
|
We do not set any If there are ENV variables in your environment like the IDF_PATH we will use that over a potential cloned repo by the build script. If you are having a IDF_PATH declared in your env you need to make sure that the version exactly matches the version set in the .cargo/config.toml. So is your version located in |
|
Can you please copy/paste the build log that is inside |
|
Adding these flags worked for me: |
These flags should anyway be in your
This ^^^ you should absolutely not do. The way to configure ESP IDF, even when Rust is used is |
|
ok so I have these two containers I do my rust things in (LXD containers). one container always worked, so I took it as a base container (cloned it) to see if I can reproduce this problem. after many hours of trying I think I finally figured out what the problem is. what I did was a system update (sudo apt update && sudo apt upgrade). and I remember that was the only thing I did on this "new" container before it started to fail. so I cloned again from my last working snapshot and took a look what actually is changing on the system. and it turns out it is the python3 package. I tried it again. clone from working container where same steps from above work (cargo generate, cargo build, etc.) and try it again after a system update, and it fails. Im pretty sure it is because of this, because there was one thing that gave it away. I had exported the ESP-IDF environment before doing the system update (and a successful cargo build) with I did the system update and ran so I am 100% sure it is due to the new python version. |
|
I can reproduce this over and over again. I roll back to the working version and cargo builds. I do a system update of ubuntu (python3 and libpython3 etc changes) and cargo build fails. so I thought, why not do looks like the problem is with the ESP-IDF repo. not esp-idf-sys. |
yes. to get the idf version, activate the ESP-IDF environment and check the version with idf.py: it is v5.4 now because I switched to a different version. in my tests it was v5.2.3 before. |
|
btw my |
|
|
ok here the reproducing of the issue: cargo build runs fine: update the ubuntu system: but cancel here. I pick only now (since this is a new shell) export ESP-IDF again here: re-run the build process: and it runs. AHA! I thought it would fail but it didn't. now let's do a system upgrade, not only python. that's what I did before as well. I only cherry-picked python3 here because I thought it was an update of python that was the issue here. let's move on: export ESP-IDF again (new shell here): build again: and it works?! I dont understand. now it works. let's try one more step. I now versions are: aaand it builds again. Im confused now. BUT WAIT...I forgot one step that I always do when spawning new containers. look at that! the RUSTFLAGS env var is exported here. I remember doing this because I read it on the web I forgot why I did this. let's rebuild again: there you go. now it fails! so I take back what I said. it's not because of some system packages, nor python3, nor libc. it is because of a single line that had been exported without notice and I didnt catch that. I will remove that line. as it turns out it is somehow dangerous to export problem solved for me. this was a great adventure of error diagnosis. |
|
Exporting |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
something has broken in the last month or so. this always worked for me. now it doesnt.
First install ESP-IDF, install for target esp32c3 and activate py environment:
now cargo generate a project from the esp-idf-template:
first of all, the esp-idf-template has the wrong
ESP_IDF_VERSION. it isv5.2.2but it should bev5.2.3. (esp-idf upstream has released v5.2.3 last month).so I bump the version in
.cargo/config.tomltov5.2.3:ESP_IDF_VERSION = "v5.2.3"(does not matter anyway, the error still exists with
v5.2.2).then
cargo build.fails with:
after failed build, check if env vars are set:
looks good.
ESP_IDF_VERSION=5.2has been set bycargo build. all the others are from activating the ESP-IDF python environment (viaexport.sh).double check to make sure that the exported ESP-IDF is really being used instead of build script fetching ESP-IDF from source:
double check that
.cargo/config.tomlrustflags look good:the template does not include
, "-C", "default-linker-libraries"(mentioned in previous issues regarding this topic), which - I guess - doesnt matter much here.I know there were a few issues regarding this problem opened in the past. but I think this one seems to be a bug.
The text was updated successfully, but these errors were encountered: