search

esp-rs / esp-idf-sys

Bindings for ESP-IDF (Espressif's IoT Development Framework)
Apache License 2.0
273 stars 123 forks source link

Error building esp-idf-sys 0.16.4 #6

Closed DavidGoodenough closed 3 years ago

DavidGoodenough commented 3 years ago

When I try to build a project with esp-idf-sys 0.16.4 I get the following error:

Compiling esp-idf-sys v0.16.4 error: failed to run custom build command for esp-idf-sys v0.16.4

Caused by: process didn't exit successfully: /home/david/src/ESP32/AcrRust/target/debug/build/esp-idf-sys-2326459d2b7cd194/build-script-build (exit status: 1) --- stdout Found compatible PlatformIO Core 5.1.1 -> /home/david/.platformio/penv/bin/platformio

--- stderr Error: Cannot derive default PIO platform, MCU and frameworks for target 'x86_64-unknown-linux-gnu'

This is on a linux (Debian) system, amd64

ivmarkov commented 3 years ago

--- stderr Error: Cannot derive default PIO platform, MCU and frameworks for target 'x86_64-unknown-linux-gnu'

Noticed the above ^^^ (emphasis mine)?

You are building the esp-idf-sys for the wrong target. There is no way to build esp-idf-sys for Linux. Only for Espressif chips.

Which brings the question: are you building the rust-esp32-std-hello binary crate, and following the instructions? Because the rust-esp32-std-hello crate does have a .cargo/config.toml file, where the correct Rust target is already specified?

Or are you trying to just build esp-idf-sys separately from rust-esp32-std-hello? That's possible, but you have to specify a bunch of command line parameters, like a correct --target as well as -Zbuild-std=.... If you are doing this, I don't see the purpose? As discussed - please try to work incrementally - build the rust-esp32-std-hello crate first. It will also build esp-idf-sys.

DavidGoodenough commented 3 years ago

On Tuesday, 10 August 2021 07:04:40 BST Ivan Markov wrote:

--- stderr Error: Cannot derive default PIO platform, MCU and frameworks for target 'x86_64-unknown-linux-gnu' Noticed the above ^^^ (emphasis mine)?

You are building the esp-idf-sys for the wrong target. There is no way to build esp-idf-sys for Linux. Only for Espressif chips.

Which brings the question: are you building the rust-esp32-std-hello binary crate, and following the instructions? Because the rust-esp32-std-hello crate does have a .cargo/config.toml file, where the correct Rust target is already specified?

Or are you trying to just build esp-idf-sys separately from rust-esp32-std-hello? That's possible, but you have to specify a bunch of command line parameters, like a correct --target as well as -Zbuild-std=.... If you are doing this, I don't see the purpose? As discussed - please try to work incrementally - build the rust-esp32-satd-hello crate first. It will also build esp-idf-sys. I was building rust-esp32-std-hello, this was just one of the stages is went through.

All I did was a "cargo build" in the rust-esp32-std-hello directory, no other parameters.
The only thing I had configured was to tell rustup that the default toolchain was the esp one.

ivmarkov commented 3 years ago

Did you switch to cargo nightly first, as described in the rust-esp32-std-hello README.md file? Did it say something during the build process? Like 'invalid target'?

It looks as if it is not picking up the target from here.

DavidGoodenough commented 3 years ago

I had an old PlatformIO setup (now deleted) which created a bad target device (esp32-c3-devkitm-1) which the build process did not like. So I removed the .platformio directory, and did a cargo clean. Running cargo build ran through a lot of stuff successfully, but then failed - generating a log of 130KB, so I reran cargo build so as just to get the error step log, and it says:- cargo build Compiling esp-idf-sys v0.16.4 error: failed to run custom build command for esp-idf-sys v0.16.4

Caused by: process didn't exit successfully: /home/david/git/rust-esp32-std-hello/target/debug/build/esp-idf-sys-54b8f62162d113ff/build-script-build (exit status: 1) --- stdout Found compatible PlatformIO Core 5.1.1 -> /home/david/.platformio/penv/bin/platformio cargo:rerun-if-changed=./patches/master_missing_xtensa_atomics_fix.diff cargo:rerun-if-changed=./patches/missing_xtensa_atomics_fix.diff cargo:rerun-if-changed=./patches/esp32c3_atomics_emul.diff cargo:rerun-if-changed=./patches/master_restore_link_fragments_for_pio.diff cargo:rerun-if-changed=./patches/pthread_destructor_fix.diff Warning! Ignore unknown configuration option patches in section [env] Processing debug (board: esp32-c3-devkitm-1; platform: espressif32; framework: espidf)

Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32-c3-devkitm-1.html PLATFORM: Espressif 32 (3.3.1) > Espressif ESP32-C3-DevKitM-1 HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa) PACKAGES:

I have the full 130KB log of the complete build if needed.

ivmarkov commented 3 years ago

When I try to build a project with esp-idf-sys 0.16.4 I get the following error:

Compiling esp-idf-sys v0.16.4 error: failed to run custom build command for esp-idf-sys v0.16.4

Caused by: process didn't exit successfully: /home/david/src/ESP32/AcrRust/target/debug/build/esp-idf-sys-2326459d2b7cd194/build-script-build (exit status: 1) --- stdout Found compatible PlatformIO Core 5.1.1 -> /home/david/.platformio/penv/bin/platformio

--- stderr Error: Cannot derive default PIO platform, MCU and frameworks for target 'x86_64-unknown-linux-gnu'

This is on a linux (Debian) system, amd64

How did you solve this??

DavidGoodenough commented 3 years ago

I deleted .platformio from my home directory, did a cargo clean, and then a cargo build. I had an old PlatformIO configuration lying around after deleting PlatformIO from my system as it clashed with other extensions of VSCode.

ivmarkov commented 3 years ago

Can you uninstall any clang you might have on your system which is installed with e.g. a package manager and then make sure that you have the Espressif provided clang on your path?

DavidGoodenough commented 3 years ago

By clang do you mean gcc or llvm? If you mean gcc then Debian won't let me, if you mean llvm then my scala-native development environment will be broken.

ivmarkov commented 3 years ago

By clang I mean clang - the c/c++ compiler toolchain based on llvm.

ivmarkov commented 3 years ago

clang is a command line executable, as well as a library (libclang.so) which can be produced when you are compiling the LLVM toolchain. The thing is, bindgen is using the libclang.so to generate the unsafe bindings to ESP-IDF APIs as part of compiling the esp-idf-sys crate.

Now, in theory, bindgen should just take the first libclang.so it finds on the $PATH (it has a complicated algorithm to detect the library which comes from another crate that it is using). Unfortunately we noticed that even if you put the clang compiled from Espressif as first on your $PATH, bindgen still has the habit of picking up other instances of the clang library, especially if you have an additional clang instance installed using the OS system packager. So in the worst case - yes - you might have to uninstall the system clang. Now, if the problem comes from the LLVM that your Scala environment is using (no idea how that is setup though - if LLVM is just statically linked into scalac, you should not have that issue! rustc is built like that - it is using LLVM itself, but in a statically linked way, as far as I'm aware), then yes - you might have to even temporarily remove the native scala environment or at least make sure it is not on your $PATH.

What we found as a workaround that might not require uninstalling other clangs is this command line: LIBCLANG_PATH=$HOME/xtensa-esp32-elf-clang/lib cargo build. You might try that first.

DavidGoodenough commented 3 years ago

OK I fixed it.

In https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa-installation-x86_64-unknown-linux-gnu.md it does not which directory you should run the commands in. I like to download TARs into a Download/TARs file, so I moved there. Unfortunately the extraction put three directories in the wrong place. The commands (at least the tar xvf ... ones) MUST be run in your HOME directory. I had assumed that the unpacked files were installed by the subsequent commands, but that would appear not to be the case.

However even after doing this, I still get the stdbool.h problem, but now that the above is fixed using:-

LIBCLANG_PATH=$HOME/xtensa-esp32-elf-clang/lib cargo build

fixes that and it builds cleanly - Hooray!