search

esp-rs / esp-idf-template

A "Hello, world!" template of a Rust binary crate for the ESP-IDF framework.
372 stars 43 forks source link

update to new esp-idf release versions #209

Closed Vollbrecht closed 1 week ago

Vollbrecht commented 1 month ago

This is just for the generation itself - CI will follow separate when we have a new esp-idf-sys/hal/svc release

Vollbrecht commented 1 month ago

This PR is still in preparation of the esp-idf-* and embuild release. Till they land it is blocked

Vollbrecht commented 1 month ago

ah i got bamboozled by the github ui ... it was the cmake ci where the no_std build fails not the cargo ones... RIP me.

no it seams esp-idf v5.2 has another problem in cargo when we build with no_std. The v5.1 runs are working. @ivmarkov do you have a idea why v5.2 failes to link here with "undefined reference to `getenv'"

ivmarkov commented 1 month ago

~ ah i got bamboozled by the github ui ... it was the cmake ci where the no_std build fails not the cargo ones... RIP me. ~

no it seams esp-idf v5.2 has another problem in cargo when we build with no_std. The v5.1 runs are working. @ivmarkov do you have a idea why v5.2 failes to link here with "undefined reference to `getenv'"

Hmm. Is getenv even defined in esp idf or is it something we patch into esp idf with link_patches? Alternatively esp idf's newlib might still be providing it via its "shims" library (don't remember its exact name) and it might be that they've removed the getenv shim in recent esp idf versions? This call does not make any sense in an environment which does not make use of processes. On the other hand, an interesting question for no_std is also WHO requires this symbol? It can't be Rust STD itself, as it is not linked in? And even if Rust std wants it, if we (i.e the template generated "hello, world" code) are not calling into it (and we shouldn't, in no_std), then who is?

Will look into it a bit more once I'm back.

ivmarkov commented 1 month ago

By the way the recently committed PR for the i2c clock does not build on the c2. You might want to look into it.

ivmarkov commented 1 month ago

It seems that esp idf itself fails (gccs eh_alloc.cc) and seems to be a linking issue in esp idf itself. Weird how it links with an idf.py build...

Vollbrecht commented 1 month ago

the c2 issue was already on my radar, i created issues on esp-idf-hal, one of them is an easy fix, the other i have to think about a bit.

Why the h2 is failing in ci i dont understand, because that is already fixed in esp-idf-hal master, and running the ci locally with the same commands work for me.

Vollbrecht commented 1 month ago

~ ah i got bamboozled by the github ui ... it was the cmake ci where the no_std build fails not the cargo ones... RIP me. ~ no it seams esp-idf v5.2 has another problem in cargo when we build with no_std. The v5.1 runs are working. @ivmarkov do you have a idea why v5.2 failes to link here with "undefined reference to `getenv'"

Hmm. Is getenv even defined in esp idf or is it something we patch into esp idf with link_patches? Alternatively esp idf's newlib might still be providing it via its "shims" library (don't remember its exact name) and it might be that they've removed the getenv shim in recent esp idf versions? This call does not make any sense in an environment which does not make use of processes. On the other hand, an interesting question for no_std is also WHO requires this symbol? It can't be Rust STD itself, as it is not linked in? And even if Rust std wants it, if we (i.e the template generated "hello, world" code) are not calling into it (and we shouldn't, in no_std), then who is?

Will look into it a bit more once I'm back.

Its double fun that it only makes a problem when we build no_std, but its working with the std build :D

ivmarkov commented 1 month ago

the c2 issue was already on my radar, i created issues on esp-idf-hal, one of them is an easy fix, the other i have to think about a bit.

Why the h2 is failing in ci i dont understand, because that is already fixed in esp-idf-hal master, and running the ci locally with the same commands work for me.

Wrong patching in the template crate then or a similar setup issue? Can't be anything else.

Vollbrecht commented 1 week ago

@ivmarkov i rerun the template CI with the now patched esp-idf-hal/svc includes and now everything in both cmake and cargo seams to be ok again. Once we go through the release i update this PR and remove the patch sections.

Vollbrecht commented 1 week ago

for a grace period of 2weeks-1month i would like to have v5.1 still in the CI, so we can observe the transition from gcc12 & gcc13 a bit better, that's why i didn't removed it.

Vollbrecht commented 1 week ago

@ivmarkov thinking about it again, we could remove the v4.4 option in the advanced path now. What do you think?

Vollbrecht commented 1 week ago

I am also thinking about some other QOL things i would like to see personally but that provably is another PR. Like having in the advanced options the capability to set "global" or ".embuild" install, or have a new option for using this template against our git versions by injecting a [patch-crates.io] section etc.

ivmarkov commented 1 week ago

@ivmarkov thinking about it again, we could remove the v4.4 option in the advanced path now. What do you think?

What is this giving us?

ivmarkov commented 1 week ago

@ivmarkov thinking about it again, we could remove the v4.4 option in the advanced path now. What do you think?

Actually, I'm fine either way. Nobody is supposed to create new project based on 4.4.X anyway.

Vollbrecht commented 1 week ago

@ivmarkov thinking about it again, we could remove the v4.4 option in the advanced path now. What do you think?

Actually, I'm fine either way. Nobody is supposed to create new project based on 4.4.X anyway.

yeah i will remove it now.