support esp32

[mykmelez]

A few things:

• cargo-cult the esp-idf-sys and embuild dependencies from other crates that build for xtensa targets;
• add the runtime feature to bindgen (so it's enabled when littlefs2-sys is built in isolation);
• add the sysroot/include directory to clang args when generating bindings in order to find header files like string.h.

These changes enable me to build littlefs2-sys in isolation for esp32s3 on both my macOS host and in an Ubuntu Docker container (running on the macOS host). It should probably be made more general, as right now it's specific to esp32s3 rather than esp32*.

As well, some version of these changes could probably be upstreamed to fix https://github.com/nickray/littlefs2/issues/18 (which is filed in the littlefs2 project although it probably needs to be fixed in littlefs2-sys), but a look at https://github.com/nickray/littlefs2-sys/pulls makes me wonder if the project is being actively maintained anymore.

[jnross]

These changes look reasonable to me, but I don't understand why it fixes things :) Does this fix the error /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found when the build is running in an arm64 Docker vm?

[nathan-whittington]

This is working on jenkins. I was able to run it on my mac as well (it was broken before).

I'd be curious to hear more about how you setup your system to build littlefs2-sys in isolation.

I guess we don't have a good way of highlighting when the build is using a system include file instead of the .embuild version.

[mykmelez]

These changes look reasonable to me, but I don't understand why it fixes things :) Does this fix the error /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found when the build is running in an arm64 Docker vm?

Yes, in my testing, although I'm not exactly sure how!

That error seems to be a common consequence of misconfiguration of the toolchain location during cross-compilation. Online, I see a lot of references to compilation issues when compiling for the same host OS at a different bit-depth, f.e. https://stackoverflow.com/questions/54082459/fatal-error-bits-libc-header-start-h-no-such-file-or-directory-while-compili, where the user appears to be building for 32-bit Linux on a 64-bit Linux machine that doesn't have the 32-bit headers/libraries (for which the solution is to install gcc-multilib).

In our case, we're compiling for an xtensa target on a Linux host, and that error presumably indicates some kind of misconfiguration of the target toolchain location. I'm not sure which change on this branch resolves that specific issue, but it may be the embuild build dependency, which perhaps sets some environment variables needed to locate the toolchain.

Perhaps it's worth teasing out these changes to determine which one resolves that specific problem, or getting feedback from Espressif Rust folk about the optimal way to cross-compile C code in Rust -sys crates like this one for xtensa targets.

[jnross]

@nathan-whittington : Since you've approved this and this is a repo you've been working primarily in, I think you should feel welcome to merged this PR as you like.

[mykmelez]

I'd be curious to hear more about how you setup your system to build littlefs2-sys in isolation.

With the Espressif toolchains (Rust, GCC, Clang) all installed on my system, I can clone this repo and issue a command like this to build it for my favorite esp32 target:

LIBCLANG_PATH="${HOME}/.espressif/tools/xtensa-esp32-elf-clang/esp-14.0.0-20220415-aarch64-apple-darwin/lib" PATH="${HOME}/.espressif/tools/xtensa-esp32s3-elf-gcc/8_4_0-esp-2021r2-patch3-aarch64-apple-darwin/bin:${PATH}" cargo +esp build --target xtensa-esp32s3-espidf "-Zbuild-std=std,panic_abort"

This is obviously suboptimal, as it requires the user to manually set LIBCLANG_PATH and PATH appropriately (as well as to specify "-Zbuild-std=std,panic_abort", which may or may not be necessary in this case, unsure).

When compiling a C project for an esp32 target with ESP-IDF, you'd source export.sh, which would configure the environment, and then idf.py build to build your project. When compiling a C project for an esp32 target with Cargo, like this one, it isn't yet clear to me how best to configure the environment.

[codysch]

Sourcing the esp-export.sh script generated by the esp rust toolchain installation (if one uses espup or if one passes the option to install-rust-toolchain.sh to generate it) sets the appropriate env variables (path & libclang) for building with cargo.