Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linkage error with Native (non PIO build) for ESP32C3 #16

Open
Tracked by #10
ivmarkov opened this issue Sep 8, 2021 · 9 comments
Open
Tracked by #10

Linkage error with Native (non PIO build) for ESP32C3 #16

ivmarkov opened this issue Sep 8, 2021 · 9 comments

Comments

@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 8, 2021

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:

@MabezDev
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Collaborator Author

ivmarkov commented Apr 5, 2023

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
Copy link

@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
image
This look fine at first sight for me because it's the same as stated above.

@ivmarkov
Copy link
Collaborator Author

ivmarkov commented Apr 6, 2023

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

@maarten2000ha
Copy link

maarten2000ha commented Apr 6, 2023

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

@Vollbrecht
Copy link
Collaborator

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

@maarten2000ha
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants