Commit Graph
6 Commits
Author SHA1 Message Date
Frantisek Hrbata 86c4c63780 fix: harden build against empty toolchain output
On some Windows systems, antivirus, endpoint-security or DLP/encryption
software intercepts short-lived toolchain processes and strips their
stdout when the build captures it through a pipe, while the same command
prints its output normally when run by hand. The tool exits successfully
but returns nothing, and each build step that reads toolchain output then
failed with a different, cryptic error far from the real cause:

- CMake configuration aborted with "Unknown arguments specified" in
  components/xtensa/project_include.cmake, or "check_expected_tool_version
  invoked with incorrect arguments" in components/esp_common.
- ldgen turned the empty objdump output into an opaque pyparsing
  "Expected 'In archive'" traceback.
- idf_tools.py silently reported the compiler/debugger version as
  "unknown", sending users into a fruitless reinstall loop.

Detect the empty result at each consumer and fail (or warn) with an
actionable message that names the likely cause and the remedy:

- tools/cmake/compiler_query.cmake: new __compiler_query() helper runs a
  compiler query and fails with a clear error on empty or failed output.
  It is a standalone module included by both the cmakev1 and cmakev2
  utilities, since the esp_common and xtensa project_include.cmake that
  call it are shared by both build systems. The xtensa if() arguments are
  now quoted so an empty result no longer collapses into a parse error.
- tools/ldgen/ldgen.py: _run_objdump() rejects empty objdump output, and
  non-empty-but-unparsable section info is caught and re-raised as a clear
  LdGenFailure instead of a raw pyparsing traceback.
- tools/idf_tools.py: empty version output now warns with the cause and
  returns UNKNOWN_VERSION instead of silently reporting "unknown".

Closes https://github.com/espressif/esp-idf/issues/18727

Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2026-08-10 09:05:01 +02:00
Frantisek Hrbata 427c5ba8df fix(xtensa/cmake): do not include project_include.cmake if the architecture is not xtensa
In cmakev2, the project_include.cmake files for every component are
included. This means that even when working with RISC-V, the
project_include.cmake file for Xtensa is still included. Ensure that the
architecture is verified, and exit if it is not Xtensa.

Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2025-10-30 17:17:49 +08:00
Frantisek Hrbata b3998f0f0c tools: strip trailing whitespaces/newline from dump_machine
In components/xtensa/project_include.cmake ${CMAKE_C_COMPILER} -dumpmachine
is called, but the output has newline.

Before
---8<--
-- Compiler supported targets: xtensa-esp32s3-elf

-- App "blink" version: 1.2.3
---8<--

After
---8<--
-- Compiler supported targets: xtensa-esp32s3-elf
-- App "blink" version: 1.2.3
---8<--

Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-05-30 13:35:10 +02:00
Ivan Grokhotkov 9d82d6bf7f xtensa: don't print debug messages to stderr
By default, CMake message() commands prints to stderr.
IDEs like Eclipse show stderr output in red, which looks as if this is
some kind of error.

Use message(STATUS) instead.
2023-04-25 12:59:41 +02:00
Alexey Gerenkov 47c2c13de5 build: Adds support for universal Clang toolchain 2022-11-23 13:25:16 +03:00
Renz Bagaporo daa13b3f62 esp32: move toolchain check 2021-03-31 19:17:33 +08:00