esp-idf-sys
esp-idf-sys copied to clipboard
Build with ESP-IDF 5.0 / master (2022-05-26) fails
Scenario:
- build a project with activated ESP-IDF from master (5.0)
- the build fails with error:
The following warnings were emitted during compilation:
warning: esp-idf version (5.0.0) not officially supported by `esp-idf-sys`. Supported versions are 'master', 'release/v4.4', 'release/v4.3', 'v4.4(.X)', 'v4.3.2'.
error: failed to run custom build command for `esp-idf-sys v0.31.5`
Caused by:
process didn't exit successfully: `/workspace/rustzx-esp32/target/release/build/esp-idf-sys-e0abd8afdf183ca3/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
cargo:warning=esp-idf version (5.0.0) not officially supported by `esp-idf-sys`. Supported versions are 'master', 'release/v4.4', 'release/v4.3', 'v4.4(.X)', 'v4.3.2'.
cargo:rerun-if-changed=/workspace/rustzx-esp32/sdkconfig.defaults
CMAKE_PREFIX_PATH_xtensa-esp32-espidf = None
CMAKE_PREFIX_PATH_xtensa_esp32_espidf = None
TARGET_CMAKE_PREFIX_PATH = None
CMAKE_PREFIX_PATH = None
CMAKE_xtensa-esp32-espidf = None
CMAKE_xtensa_esp32_espidf = None
TARGET_CMAKE = None
CMAKE = None
running: "cmake" "/workspace/rustzx-esp32/target/xtensa-esp32-espidf/release/build/esp-idf-sys-7fb14e0cab432a5e/out" "-G" "Ninja" "-DCMAKE_TOOLCHAIN_FILE=/home/gitpod/.espressif/frameworks/esp-idf-master/tools/cmake/toolchain-esp32.cmake" "-DCMAKE_BUILD_TYPE=" "-DCMAKE_INSTALL_PREFIX=/workspace/rustzx-esp32/target/xtensa-esp32-espidf/release/build/esp-idf-sys-7fb14e0cab432a5e/out" "-DCMAKE_C_FLAGS= -mlongcalls -Wno-frame-address -ffunction-sections -fdata-sections" "-DCMAKE_CXX_FLAGS= -mlongcalls -Wno-frame-address -ffunction-sections -fdata-sections" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections"
-- Found Git: /usr/bin/git (found version "2.36.1")
-- The C compiler identification is GNU 8.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/gitpod/.espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking Python dependencies...
-- Configuring incomplete, errors occurred!
See also "/workspace/rustzx-esp32/target/xtensa-esp32-espidf/release/build/esp-idf-sys-7fb14e0cab432a5e/out/build/CMakeFiles/CMakeOutput.log".
--- stderr
Using activated esp-idf v5.0.0 environment at '/home/gitpod/.espressif/frameworks/esp-idf-master'
ERROR: /workspace/rustzx-esp32/.embuild/espressif/python_env/idf5.0_py3.8_env/bin/python doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it
CMake Error at /home/gitpod/.espressif/frameworks/esp-idf-master/tools/cmake/build.cmake:286 (message):
Some Python dependencies must be installed. Check above message for
details.
Call Stack (most recent call first):
/home/gitpod/.espressif/frameworks/esp-idf-master/tools/cmake/build.cmake:415 (__build_check_python)
CMakeLists.txt:6 (idf_build_process)
thread 'main' panicked at '
command did not execute successfully, got: exit status: 1
build script failed, must exit now', /home/gitpod/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.48/src/lib.rs:975:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
How to simulate:
- open: https://gitpod.io/github.com/georgik/rustzx-esp32/tree/feature/feature/esp32-esp-idf-5.0
- run:
./run-wokwi.sh - the build fails
Note:
- build script runs:
cargo +esp build --target xtensa-esp32-espidf --release --features "esp32_ili9341"
Workaround:
mkdir .embuild/espressif/python_env
ln -s ~/.espressif/python_env/idf5.0_py3.8_env/ .embuild/espressif/python_env/idf5.0_py3.8_env
It seems that .embuild assumes different location of activated python environment in case of idf5.0. The symlink should not be necessary.
I believe the fix for this is to add ESP_IDF_TOOLS_INSTALL_DIR = { value = "fromenv" } to .cargo/config.toml. In reality, it should be possible to find the tools dir from the activated esp-idf environment, right @N3xed?
This is a really strange error. Assuming ESP_IDF_TOOLS_INSTALL_DIR is unset or set to fromenv and there is a valid activated esp-idf environment this should not be happening.
When detecting the activated esp-idf environment we get the python that we use straight from $PATH (here) and this works and the python dependencies check that embuild::espidf::EspIdf::try_from_env does also succeeds, so I'm really not sure why esp-idf's CMake build system decides to use another python (we forward the exact same $PATH to cmake).
IDF v5.0 will be released the next week. I re-run the scenario to refresh state of the issue with Toolchain 1.62.1.0 and activated ESP-IDF on Windows and the error seems to be present also here.
I believe the fix for this is to add ESP_IDF_TOOLS_INSTALL_DIR = { value = "fromenv" } to .cargo/config.toml. In reality, it should be possible to find the tools dir from the activated esp-idf environment, right @N3xed?
Does this not fix it? Whilst @N3xed is right, it should be automatically detected, if we can get it working by explicitely setting the tools path then we should. At least then we can run esp-idf v5 in CI and start fixing the other build issues.
The python error should have been fixed with commit 7e1fc9186e7adc5b59eaeb13f2f6478068767a8c. If not this needs some deeper investigation (as it doesn't happen for me).
There are two other issues though:
-
Since we're currently including legacy
i2sAPIs for the bindings, bindgen generates twoi2s_channel_ttypes. One fordeprecated/driver/i2s_types_legacy.h:75and one for the forward declared struct ininclude/driver/i2s_types.h:66. To get around this I've added the patchi2s_types_master.diff. -
https://github.com/espressif/esp-idf/issues/8787 On Windows symlinks require administrator privileges and hard-links don't go across filesystem boundaries (i.e. two different drives). This wasn't an issue in esp-idf v4 since this function wasn't used for the normal build (I think it was used for testing only).
Other than that it compiles for me (though with lots of deprecation warnings).
The python error should have been fixed with commit https://github.com/esp-rs/esp-idf-sys/commit/7e1fc9186e7adc5b59eaeb13f2f6478068767a8c. If not this needs some deeper investigation (as it doesn't happen for me).
I'm still running into this issue, for some reason without the ESP_IDF_TOOLS_INSTALL_DIR env var specified, embuild is looking in the local directory for the tools:
ERROR: /home/mabez/development/rust/embedded/experiments/esp-float-crash/.embuild/espressif/python_env/idf5.1_py3.10_env/bin/python doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it
As far as I am aware, all these issues have been addressed. Closing.
I just ran into this issue
Using activated esp-idf v5.1.0 environment at '/Users/fuzz/esp/esp-idf'
ERROR: /Users/fuzz/boondocker/rs485-bridge/.embuild/espressif/python_env/idf5.1_py3.10_env/bin/python doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it
I just ran into this issue
Using activated esp-idf v5.1.0 environment at '/Users/fuzz/esp/esp-idf' ERROR: /Users/fuzz/boondocker/rs485-bridge/.embuild/espressif/python_env/idf5.1_py3.10_env/bin/python doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it
This issue should be fixed in esp-idf-sys master (see this comment).