Unable to compile esp-idf-svc as a dependency

[thefill]

Hey guys,
just tried to build project for ESP32 with IDF release/v4.4.2 and esp-idf-svc 0.42.3

Getting following error when building esp-idf-svc dep.:

error[E0063]: missing fields `enable_so_linger` and `linger_timeout` in initializer of `httpd_config`
  --> /home/esp/.cargo/registry/src/github.com-1ecc6299db9ec823/esp-idf-svc-0.42.3/src/http/server.rs:63:14
   |
63 |         Self(httpd_config_t {
   |              ^^^^^^^^^^^^^^ missing `enable_so_linger` and `linger_timeout`

error[E0063]: missing fields `enable_so_linger` and `linger_timeout` in initializer of `httpd_config`
   --> /home/esp/.cargo/registry/src/github.com-1ecc6299db9ec823/esp-idf-svc-0.42.3/src/httpd.rs:394:9
    |
394 |         esp_idf_sys::httpd_config_t {
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `enable_so_linger` and `linger_timeout`
error: could not compile `esp-idf-svc` due to 2 previous errors

Looks like those 2 fields are required according to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_http_server.html

[Vollbrecht]

yesterday i also encountered this error. the problem occurs when using a new esp-idf environment. When using buildscripts, a automated docker file or something that installs with the "install-rust.toolchain." than a "fix" to the problem currently is.
When installing:

1. dont use "release/v4.4" as the ESP_IDF_VERSION rather use "v.4.4.2"
2. dont use "esp32" as --build-target argument rather use "esp32s3", "esp32c3" or "all"

In hope this helps you!

[pyaillet]

The origin of the problem comes from an evolution on esp-idf release/v4.4.
I hoped for a quick fix, but it turns out it's not easy to differentiate between release/v4.4 and v4.4.{1,2}.
Fix could be to force v4.4.2 on projects like @Vollbrecht suggested until there is a v4.4.3

[thefill]

thanks for clarification @pyaillet. Tried quickly fix my devcontainer setup with @Vollbrecht proposed "fix" but looks like its not as easy - some internal scripts are incorrectly linking to cmake using non-existing path to esp-idf v4.4.

[Vollbrecht]

thanks for clarification @pyaillet. Tried quickly fix my devcontainer setup with @Vollbrecht proposed "fix" but looks like its not as easy - some internal scripts are incorrectly linking to cmake using non-existing path to esp-idf v4.4.

i had the problem yesterday also, this happens because of caching. you need to make sure that you delete cached containers on your machine. at least that was a problem for me.
Check docker system df
First delete some image. when images are deleted they still are in the build cache. thats a big gotcha. you than have to delete the cache after deleting the images !

Docker dont realize that you changed the build script and haply uses the cached variants...

[thefill]

thanks for clarification @pyaillet. Tried quickly fix my devcontainer setup with @Vollbrecht proposed "fix" but looks like its not as easy - some internal scripts are incorrectly linking to cmake using non-existing path to esp-idf v4.4.

i had the problem yesterday also, this happens because of caching. you need to make sure that you delete cached containers on your machine. at least that was a problem for me. Check docker system df First delete some image. when images are deleted they still are in the build cache. thats a big gotcha. you than have to delete the cache after deleting the images !

Docker dont realize that you changed the build script and haply uses the cached variants...

yep, I can confirm that was the case. All works now.

@pyaillet if you need any help around detection of this version - I'm more than happy to help. I assume all boils down to IDF having quite weird strategy for releases (branch vs tag) so they weirdly try to differentiate between minor and patch updates?

Any place where I can take a look how its all detected? Loads of moving parts in those setups...

[ivmarkov]

Fixed by a81ce44