esp-idf-sys: ESP-IDF master and v5.1-dev compile errors for RISC-V
ESP-IDF v5.1-dev appears to have changed something that breaks esp-idf-sys’ builds with errors like this:
.../components/riscv/include/riscv/rv_utils.h: Assembler messages:
.../components/riscv/include/riscv/rv_utils.h:79: Error: unrecognized opcode `csrw mtvec,a5', extension `zicsr' required
I did some debugging and the command-line is different if I go mucking around in .embuild manually. Here’s the output snippet for esp-idf-sys building things:
https://gist.github.com/07fd83db22a882c5e11af103d1bf4c85
And here’s the working command from idf.py -v build in one of the samples from the same .embuild dir:
https://gist.github.com/d360c2e6f716af9416d7e29428348742
Biggest difference I see is that the cargo build passes -march twice (!?!) and also -mabi/-mcmodel, but idf.py doesn’t.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 19 (10 by maintainers)
Did some more sleuthing and found this is the problem: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.1/gcc.html#risc-v-builds-outside-of-idf
The issue is that esp-idf-sys’ cargo_driver.rs is correctly scraping the
-march=rv32imc_zicsr_zifenceiflag, but cmake-rs is picking up defaults fromcc::Buildthat hardcode adding-march=rv32imc -mabi=ilp32 -mcmodel=medany(see https://github.com/rust-lang/cc-rs/blob/main/src/lib.rs#L1956-L1980). This can be worked around a few different ways I think, but sadly I can’t test them because I’m getting other build errors due to some minor changes in v5.1 that confuses bindgen (ledc_clk_cfg_t is an alias for soc_periph_ledc_clk_src_legacy_t, but bindgen doesn’t know to redefine all the constants too apparently).See https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 for more details. I think we’ve gotta patch
cc-rsagain :\