Esp32 compilation error after enabling CONFIG_NEWLIB_LIBC

[lgl88911]

Describe the bug
Esp32 compilation error after enabling CONFIG_NEWLIB_LIBC

To Reproduce
Steps to reproduce the behavior:

1. Add CONFIG_NEWLIB_LIBC=y to samples\hello_world\prj.conf
2. west build -p auto -b esp32 samples/hello_world/
3. See build error

Expected behavior
Build pass

Impact
I want to use Zephyr's posix on esp32

Logs and console output
The error message shows that zephyr's build system first finds the posix header file in hal_espresslf, and the inconsistency of its API definition and zephyr leads to an error.

In file included from /mnt/e/tomato/t-clock-master/zephyr/lib/posix/pthread_common.c:10:
/mnt/e/tomato/t-clock-master/zephyr/include/posix/time.h:90:15: error: static declaration of 'clock_gettime' follows non-static declaration
 __syscall int clock_gettime(clockid_t clock_id, struct timespec *ts);
               ^~~~~~~~~~~~~
In file included from /mnt/e/tomato/t-clock-master/zephyr/include/posix/time.h:12,
                 from /mnt/e/tomato/t-clock-master/zephyr/lib/posix/pthread_common.c:10:
/home/frank/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/xtensa-esp32-elf/sys-include/time.h:187:5: note: previous declaration of 'clock_gettime' was here
 int clock_gettime (clockid_t clock_id, struct timespec *tp);
     ^~~~~~~~~~~~~
In file included from /mnt/e/tomato/t-clock-master/zephyr/lib/posix/pthread_common.c:10:
/mnt/e/tomato/t-clock-master/zephyr/include/posix/time.h:94:5: error: conflicting types for 'timer_create'
 int timer_create(clockid_t clockId, struct sigevent *evp, timer_t *timerid);
     ^~~~~~~~~~~~
In file included from /mnt/e/tomato/t-clock-master/zephyr/include/posix/time.h:12,
                 from /mnt/e/tomato/t-clock-master/zephyr/lib/posix/pthread_common.c:10:
/home/frank/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/xtensa-esp32-elf/sys-include/time.h:192:5: note: previous declaration of 'timer_create' was here
 int timer_create (clockid_t clock_id,
     ^~~~~~~~~~~~
[18/49] Building C object zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj

[stephanosio]

@sylvioalves It looks like there are some compatibility issues with the newlib provided by the Espressif toolchain.

[sylvioalves]

@stephanosio @tejlmand, There is no support yet for newlib on esp32. I have started working on it a few weeks ago and will eventually update the toolchain to allow this. This #38540 was part of it. This PR improves Espressif's toolchain handling, allowing new version to be seamlessly updated using proper command.
However, I would like to ask you both: What would be the proper way for me to inform users that toolchain update is necessary (like this very same issue). Over cmake message and toolchain version comparison?

Zephyr uses this strategy for cmake version and SDK, with a warning message and build failure.

[tejlmand]

There is no support yet for newlib on esp32.

just on the esp32 target or in general the espressif toolchain ?
If the latter, then this line:

zephyr/cmake/toolchain/espressif/target.cmake

Line 27 in 6020afe

set(TOOLCHAIN_HAS_NEWLIB ON CACHE BOOL "True if toolchain supports newlib")

should probably have been:

set(TOOLCHAIN_HAS_NEWLIB OFF CACHE BOOL "True if toolchain supports newlib")

[sylvioalves]

@tejlmand Toolchain supports newlib in esp-idf, however, needs some updates to work in Zephyr's. One of the issues are the one related in this ticket. ESP32 toolchain time.h differs from Zephyr's and conflicting types happens. I did not find a way to fix this without rebuilding the toolchain. And also previous declaration warnings.
/home/frank/.espressif/tools/xtensa-esp32-elf/esp-2020r3-8.4.0/xtensa-esp32-elf/xtensa-esp32-elf/sys-include/time.h:187:5: note: previous declaration of 'clock_gettime' was here

set(TOOLCHAIN_HAS_NEWLIB OFF CACHE BOOL "True if toolchain supports newlib")
Well, toolchain has newlib support, however is not ready for Zephyr yet. You are correct.

[danielschenk]

Any plans for a fix, or maybe a workaround which can be used in the meantime (like a custom-built toolchain)? I'm trying to port an application to ESP32, which was originally developed with Nordic Connect SDK (also Zephyr) for an nRF board. I hoped that because of already using Zephyr, my porting effort would be minimal, but I'm now getting blocked by a dependency on <algorithm>, <array>, and <cassert> in a 3rd-party C++ lib I'm using.

As ESP32 support in Zephyr is currently expanding, this is a critical feature IMO.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[tejlmand]

Re-opened, as this is still valid.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[cdrx]

Bump

[Oreobird]

Is this still WIP? Recently I try to run microTVM auto tuning example on ESP32 with Zephyr，but got the exactly same error.

[sylvioalves]

Merged: #43534