ESP-IDF on FreeBSD: Toolchain rejects toolchain due to crosstool-ng tagging as UNKNOWN
Posted: Sat Oct 19, 2024 8:23 am
With an update of port devel/xtensa-esp-elf and some own tweaks as well as with the (private) port provided of T. Sakurai (trombik) on github.com (xtensa-esp32-elf, now providing also a LLVM derived/focussed toolchain), one is able to use a decent toolchain on FreeBSD.
To some extend I'm able to utilize some of the crucial Python based tools for the convenience of using the official ESP-IDF, but not without minor tweaks.
The main problem I face is that the ESP-IDF derives a toolchain tag from the toolchain binaries via a Python script. Since the toolchain is then nailed down to a specific ESP-IDF, and the toolchain's binaries are identified as:
[... ESP-IDF v5.3 ...]
[esp-idf]: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc --version
==>> xtensa-esp-elf-gcc (crosstool-NG UNKNOWN) 13.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]
My setup is the most simplest cmake setup for a demonstration project you can imagine and simply taken from the ESP-IDF handbook, so nothing fancy, simply inlcuding the regular stuff. So, the IDF tools respond to this with (idf.py menuconfig) due to a check (/pool/home/itsme/Projects/esp-idf/tools/cmake/tool_version_check.cmake):
[...]
[rollmops]: idf.py menuconfig
Executing action: menuconfig
Running cmake in directory /pool/home/itsme/Projects/esp-dev.git/rollmops/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DPYTHON=/usr/local/bin/python -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 /pool/home/itsme/Projects/esp-dev.git/rollmops"...
-- IDF_TARGET is not set, guessed 'esp32' from sdkconfig '/pool/home/itsme/Projects/esp-dev.git/rollmops/sdkconfig'
-- Found Git: /usr/local/bin/git (found version "2.47.0")
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32
-- Project sdkconfig file /pool/home/itsme/Projects/esp-dev.git/rollmops/sdkconfig
-- Compiler supported targets: xtensa-esp-elf
CMake Error at /pool/home/itsme/Projects/esp-idf/tools/cmake/tool_version_check.cmake:36 (message):
Tool doesn't match supported version from list ['esp-14.2.0_20240906']:
/usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc
Please try to run 'idf.py fullclean' to solve it.
[...]
I have managed to build the FreeBSD port provided toolchain to include a tag, so the binary's version is correctly shown as
[...]
[esp-idf]: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc --version
xtensa-esp-elf-gcc (crosstool-NG esp-14.2.0_20240906) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]
but this makes it impossible to switch between ESP-IDF v5.3 and v5.4.
The binary's identification tag is imprinted when crosstool-ng is built and is in fact the crosstool-ng version as far as I can fathom.
QUESTION:
How can I force the ESP-IDF v5.3 and/or v5.4 to bahve amnesiac on the crosstool-ng version used and therefore the binaries of the toolchain tagged for? Did I oversaw something in the ESP-IDF handbook (which is, in contrary to an earlier statement I lost here is quite good and covering really many aspects ...)?
Thank you in advance.
To some extend I'm able to utilize some of the crucial Python based tools for the convenience of using the official ESP-IDF, but not without minor tweaks.
The main problem I face is that the ESP-IDF derives a toolchain tag from the toolchain binaries via a Python script. Since the toolchain is then nailed down to a specific ESP-IDF, and the toolchain's binaries are identified as:
[... ESP-IDF v5.3 ...]
[esp-idf]: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc --version
==>> xtensa-esp-elf-gcc (crosstool-NG UNKNOWN) 13.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]
My setup is the most simplest cmake setup for a demonstration project you can imagine and simply taken from the ESP-IDF handbook, so nothing fancy, simply inlcuding the regular stuff. So, the IDF tools respond to this with (idf.py menuconfig) due to a check (/pool/home/itsme/Projects/esp-idf/tools/cmake/tool_version_check.cmake):
[...]
[rollmops]: idf.py menuconfig
Executing action: menuconfig
Running cmake in directory /pool/home/itsme/Projects/esp-dev.git/rollmops/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DPYTHON=/usr/local/bin/python -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 /pool/home/itsme/Projects/esp-dev.git/rollmops"...
-- IDF_TARGET is not set, guessed 'esp32' from sdkconfig '/pool/home/itsme/Projects/esp-dev.git/rollmops/sdkconfig'
-- Found Git: /usr/local/bin/git (found version "2.47.0")
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32
-- Project sdkconfig file /pool/home/itsme/Projects/esp-dev.git/rollmops/sdkconfig
-- Compiler supported targets: xtensa-esp-elf
CMake Error at /pool/home/itsme/Projects/esp-idf/tools/cmake/tool_version_check.cmake:36 (message):
Tool doesn't match supported version from list ['esp-14.2.0_20240906']:
/usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc
Please try to run 'idf.py fullclean' to solve it.
[...]
I have managed to build the FreeBSD port provided toolchain to include a tag, so the binary's version is correctly shown as
[...]
[esp-idf]: /usr/local/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc --version
xtensa-esp-elf-gcc (crosstool-NG esp-14.2.0_20240906) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[...]
but this makes it impossible to switch between ESP-IDF v5.3 and v5.4.
The binary's identification tag is imprinted when crosstool-ng is built and is in fact the crosstool-ng version as far as I can fathom.
QUESTION:
How can I force the ESP-IDF v5.3 and/or v5.4 to bahve amnesiac on the crosstool-ng version used and therefore the binaries of the toolchain tagged for? Did I oversaw something in the ESP-IDF handbook (which is, in contrary to an earlier statement I lost here is quite good and covering really many aspects ...)?
Thank you in advance.