Ci for idf 5.0

[usbalbin]

Update CI to also run for IDF 5.0

[usbalbin]

Any ideas as to why I get this error?

= note: [ldproxy] Running ldproxy
          Error: Linker /home/runner/work/esp-idf-hal/esp-idf-hal/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc failed: exit status: 1
          STDERR OUTPUT:
          /home/runner/work/esp-idf-hal/esp-idf-hal/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /home/runner/work/esp-idf-hal/esp-idf-hal/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti/libc.a(lib_a-vfprintf.o): in function `_vfprintf_r':
          /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:1192: undefined reference to `__trunctfdf2'
          collect2: error: ld returned 1 exit status
          
          
          Stack backtrace:
             0: anyhow::error::<impl anyhow::Error>::msg
             1: ldproxy::main
             2: std::sys_common::backtrace::__rust_begin_short_backtrace
             3: std::rt::lang_start::{{closure}}
             4: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/core/src/ops/function.rs:606:13
             5: std::panicking::try::do_call
                       at /rustc/32e613bbaafee1bcabba48a2257b[83](https://github.com/esp-rs/esp-idf-hal/actions/runs/3608558268/jobs/6081239029#step:14:84)8f8d1c03d3/library/std/src/panicking.rs:483:40
             6: std::panicking::try
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/panicking.rs:447:19
             7: std::panic::catch_unwind
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/panic.rs:137:14
             8: std::rt::lang_start_internal::{{closure}}
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/rt.rs:148:48
             9: std::panicking::try::do_call
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/panicking.rs:483:40
            10: std::panicking::try
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/panicking.rs:447:19
            11: std::panic::catch_unwind
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/panic.rs:137:14
            12: std::rt::lang_start_internal
                       at /rustc/32e613bbaafee1bcabba48a2257b838f8d1c03d3/library/std/src/rt.rs:148:20
            13: main
            14: <unknown>
            15: __libc_start_main
            16: _start
          
  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `esp-idf-hal` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `esp-idf-hal` due to previous error
Error: Process completed with exit code [101](https://github.com/esp-rs/esp-idf-hal/actions/runs/3608558268/jobs/6081239029#step:14:102).

[zRedShift]

@usbalbin Maybe the esp-2021r2-patch5-8.4.0 toolchain is too old, I'm using esp-2022r1-11.2.0 and it has the __trunctfdf2 symbol.

[usbalbin]

Why are we not getting the latest? Could that be a limitation of the install script vs espup? Or is that something else?

[zRedShift]

It's probably an espup limitation, esp-idf's install.sh seems to do everything properly.

[usbalbin]

It's probably an espup limitation, esp-idf's install.sh seems to do everything properly.

But esp-rs/[email protected] is using the script, right?

[usbalbin]

I can not quite wrap my head around why the same command seems to work for me locally.

The test that fails riscv32imc-esp-espidf, release/v4.4 does not even download the xtensa toolchain using the install script.

Does that mean that somehow esp-idf-sys's build script(?) downloads the tools mentioned in the error? And for some reason it selects old versions of those during CI(but not for me locally)?

/home/runner/work/esp-idf-hal/esp-idf-hal/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /home/runner/work/esp-idf-hal/esp-idf-hal/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti/libc.a(lib_a-vfprintf.o): in function `_vfprintf_r':
          /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:1192: undefined reference to `__trunctfdf2'
          collect2: error: ld returned 1 exit status
          

---

What I have done locally to try and replicate the error:

• xtensa toolchain via espup update, done since before
• install ncurses5
• rustup update
• rustup override set nightly # Dont use the xtensa toolchain, just for this test
• rm -rf .embuild
• cargo clean
• ESP_IDF_VERSION="release/v4.4" cargo build --examples --target riscv32imc-esp-espidf -Zbuild-std=std,panic_abort -Zbuild-std-features=panic_immediate_abort
• no error...

[zRedShift]

@usbalbin esp-idf-sys definitely downloads all these tools, or rather, it runs a script that does. There's also platformIO integration, but I never tried anything other than the native/cmake builds, @ivmarkov any leads?

[ivmarkov]

Missing rustflags that you do need for riscv32imc-esp-espidf?

[usbalbin]

Missing rustflags that you do need for riscv32imc-esp-espidf?

Oh, Thanks a lot! Will give it a try

[usbalbin]

Do we want to merge this or should these changes be made as part of #132? In my opinion #132 does not make sense to merge without having some kind of CI for IDF 5.0. Or other thoughts? :)

[ivmarkov]

Sure, Ill get there soon.