Linkage error with Native (non PIO build) for ESP32C3

[ivmarkov]

When using the native build, the linking phase fails with the following errors:

Error: Linker /Users/imarkov/projects/esp32/rust-esp32-std-hello/.sdk/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc failed: exit status: 1
STDERR OUTPUT:
/Users/imarkov/projects/esp32/rust-esp32-std-hello/.sdk/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /Users/imarkov/projects/esp32/rust-esp32-std-hello/.sdk/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/lib/rv32im/ilp32/libc.a(lib_a-svfprintf.o): in function `_svfprintf_r':
/builds/idf/crosstool-NG/.build/HOST-x86_64-apple-darwin12/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:1217: undefined reference to `__trunctfdf2'
/Users/imarkov/projects/esp32/rust-esp32-std-hello/.sdk/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /Users/imarkov/projects/esp32/rust-esp32-std-hello/.sdk/tools/riscv32-esp-elf/1.24.0.123_64eb9ff-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/lib/rv32im/ilp32/libc.a(lib_a-vfprintf.o): in function `_vfprintf_r':
/builds/idf/crosstool-NG/.build/HOST-x86_64-apple-darwin12/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:1192: undefined reference to `__trunctfdf2'
collect2: error: ld returned 1 exit status

Preliminary analysis:

I am half there in figuring out the linkage problems with the native build and the C3 chip:

• Rust is spitting out a -nodefaultlibs option on the command line, which seems to be kind of like "the default behavior" (but it seems you can control this on a Rust target level, when you define the target)
• This is somehow preventing the linker from finding the missing intrinsic (__trunctfdf2); if I remove the -nodefaultlibs, it works OK
• Short term solution: we have a simple workaround in adding a rustflags = ["-C", "default-linker-libraries"] to the [target.riscv32imc-esp-espidf] section in .cargo/config.toml in the relevant binary crate (rust-esp32-std-hello etcetera)
• Long term solution: we should probably allow the "default libs" behavior on the Rust target level (as in riscv32imc-esp-espidf as well as in all xtensa targets, if it is not allowed there). Reason why I believe this is a correct behavior: I don't see the -nodefaultlibs argument amongst the "native" (cmake) args, which means the native ESP-IDF build is assuming it is NOT set

Unresolved questions/issues:

• Why is this argument defined in the first place? The Rust/cargo committers are fuzzy on the topic:
  • Option to disable -nodefaultlibs to the linker rust-lang/rust#54237
  • alexcrichton/rust@6f4b378#diff-7ece3daa669e665894c845baaf8c173af652c56ad5306e18c74504f9df2577faR1141
• Why does the build work for the Xtensa targets? Either they opt out from the -nodefaultlibs option, or that particular intrinsic is simply not needed on Xtensa. Not sure
• Why does the ESP32C3 build work via PlatformIO? Superstrange.

[MabezDev]

I might have figured part of this out, at least the difference between pio & espressif tools chains for RISCV.

Espressif:

.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-8.4.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc -dumpspecs | grep "\-lnosys"
-lc -lnosys -lc

PIO:

.embuild/platformio/packages/toolchain-riscv32-esp/bin/riscv32-esp-elf-gcc -dumpspecs | grep "\-lnosys"

However Xtensa is the same:

Espressif:

.embuild/espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -dumpspecs | grep "\-lnosys"
-lc -lnosys -lc

PIO:

.embuild/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -dumpspecs | grep "\-lnosys"
-lc -lnosys -lc

Seems PIO guys have ran into this issue to and dropped that -lnosys flag from their toolchain spec?

Still no idea why this works for Xtensa though, perhaps the intrinsic calls just aren't being generated?

[rherrmannr]

Using

[target.riscv32imc-esp-espidf]
linker = "ldproxy"
rustflags = ["-C", "default-linker-libraries"]

worked for me. Thanks for this hint.
I've encountered this problem using mqtt_protocol="0.11"

[maarten2000ha]

I am trying to get the esp edf template to build on mac m1 pro but I keep getting errors. Firstly it was due to the nightly toolchain not being used (Wasn't documented how I could change it so didn't know). Eventually after reinstalling rust, ldproxy, cargo-generate, espup and installing espup and exporting it. I stumble upon another issue which really sounds alot like the one stated above. a gist with the error I get. Not sure if this is related to this issue but if not let me know what I can do to get this issue solved.

[ivmarkov]

I am trying to get the esp edf template to build on mac m1 pro but I keep getting errors. Firstly it was due to the nightly toolchain not being used (Wasn't documented how I could change it so didn't know).

It is documented now. Hope that helps. With that said, this is pretty basic.

Eventually after reinstalling rust, ldproxy, cargo-generate, espup and installing espup and exporting it. I stumble upon another issue which really sounds alot like the one stated above. a gist with the error I get. Not sure if this is related to this issue but if not let me know what I can do to get this issue solved.

Most likely it is related, and my hypothesis would be that you are simply missing this flag or the whole .cargo/config.toml file from your project.

[maarten2000ha]

@ivmarkov Thank you for updating the documentation and helping me out.

I just generated a project with the edf template, this template give an .cargo/config.toml file which currently look like this for me

This look fine at first sight for me because it's the same as stated above.

[ivmarkov]

Are you saying that the just-generated project fails for you with the same error?

[maarten2000ha]

Yes, A just-generated project also fails. It looks like it is also a different error than before.

[Vollbrecht]

could be related to the changes in espup ? esp-rs/espup@7271dbc

[maarten2000ha]

My issue stated above was caused due to rustflags being in my zshrc 😉. Thank you for the help and hopefully, I can soon help fix this issue for the long term.