Both newlib and picolibc headers in toolchain 16.1 declare timespec_get()
but the archives do not define it. Provide the missing C11 implementation
through esp_libc, mapping TIME_UTC to clock_gettime(CLOCK_REALTIME).
Closes https://github.com/espressif/esp-idf/issues/18889
Sub-projects like ULP are built as external CMake projects via
externalproject_add() and may use toolchains that are completely
different from the IDF target toolchain. For example, the ULP RISC-V
co-processor on an xtensa target (ESP32-S2/S3) uses
riscv32-esp-elf-gcc while the main project uses xtensa-esp-elf-gcc.
This causes problems in cmakev2:
1. __init_toolchain() in idf.cmake validates that CMAKE_TOOLCHAIN_FILE
matches IDF_TARGET and then overrides it. For sub-projects with
custom toolchains (passed via -DCMAKE_TOOLCHAIN_FILE from the
parent), this validation fails because the toolchain doesn't follow
the IDF naming convention (toolchain-<target>.cmake).
2. Several component project_include.cmake files use functions from
the IDF toolchain response file machinery (idf_toolchain_add_flags,
idf_toolchain_remove_flags, idf_toolchain_rerun_abi_detection) that
are not available in sub-projects with custom toolchains, or perform
validation that assumes the IDF target toolchain is in use.
Introduce IDF_CUSTOM_TOOLCHAIN, a CMake variable passed via -D from
the parent build to indicate that the toolchain was provided externally
and should not be resolved or validated by the IDF build system.
When IDF_CUSTOM_TOOLCHAIN is set:
- __init_toolchain() records the pre-set CMAKE_TOOLCHAIN_FILE and
skips IDF_TARGET-based resolution and validation.
- Component project_include.cmake files that manipulate IDF toolchain
flags (xtensa, esp_libc, esp_psram, soc) return early, as those
operations are not applicable to custom toolchains.
This is a generic mechanism usable by any sub-project that provides
its own toolchain (ULP, or any future sub-project with a non-IDF
toolchain).
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
On the Linux target the host's C library is used directly; none of the
LibC menu options apply. Mark the entire "LibC" menu as `depends on
!IDF_TARGET_LINUX` so its symbols (LIBC_NEWLIB, LIBC_PICOLIBC, …) stay
undefined on Linux builds.
Also gate the picolibc-specific include in components/console/linenoise/
linenoise.c under `!CONFIG_IDF_TARGET_LINUX` so the file does not try to
pull <stdio-bufio.h> on the host even if CONFIG_LIBC_PICOLIBC is set by
some other build path.
Use real CI config names and minimal config aliases so these tests are
collected and built again instead of silently being skipped.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Made-with: Cursor
The --gc-sections flag in picolibc.specs causes CMake compiler detection
to fail by dropping required data. Work around this by creating a modified
specs file without the flag.
- Also fixed an issue where NewLib ROM APIs, when called from TEE, were
using the syscall table located in the REE SRAM. This could be abused
as an attack vector to invoke illegal functions from the TEE.
To prevent this, the syscall table is now switched to the TEE-specific
copy during every M-U mode transition.
