SDK v0.16.9-rc2 build issue for zephyr v3.7-branch

[pdgendt]

Zephyr version as of writing: https://github.com/zephyrproject-rtos/zephyr/commit/53738cf92479610bcf79fe738636a2b920224a36 SDK v0.16.9-rc2

# current main has the 'sdk' command
$ west sdk install -b ~/.local/opt --version 0.16.9-rc2 --toolchain arm-zephyr-eabi
$ git checkout v3.7-branch
$ west update # making sure hal_nxp is up-to-date
$ west build -b mimxrt1064_evk samples/hello_world

The following output is printed:

In file included from /home/pdgendt/dev/zephyr-main/zephyr/include/zephyr/posix/sys/stat.h:40,
                 from /home/pdgendt/dev/zephyr-main/zephyr/lib/libc/picolibc/libc-hooks.c:10:
/home/pdgendt/dev/zephyr-main/zephyr/include/zephyr/posix/posix_types.h:77:18: error: conflicting types for 'clockid_t'; have 'uint32_t' {aka 'unsigned int'}
   77 | typedef uint32_t clockid_t;
      |                  ^~~~~~~~~
In file included from /home/pdgendt/dev/zephyr-main/zephyr/include/zephyr/posix/posix_types.h:11:
/home/pdgendt/.local/opt/zephyr-sdk-0.16.9-rc2/arm-zephyr-eabi/picolibc/include/sys/types.h:217:25: note: previous declaration of 'clockid_t' with type 'clockid_t' {aka 'long unsigned int'}
  217 | typedef __clockid_t     clockid_t;
      |                         ^~~~~~~~~

EDIT:

Also confirmed for aarch64-zephyr-elf toolchain.

[stephanosio]

It looks like we need to backport https://github.com/zephyrproject-rtos/zephyr/commit/9da477543d13a8b9b6e65017091f2192990e38f0 to the v3.7-branch.

In fact, we should consider backporting the entire series pulling Picolibc 1.8.7 and 1.8.8 to v3.7 (LTS) so that the Zephyr LTS and the latest SDK 0.16.x Picolibc versions are in sync.

cc @keith-packard

[keith-packard]

It looks like we need to backport zephyrproject-rtos/zephyr@9da4775 to the v3.7-branch.

In fact, we should consider backporting the entire series pulling Picolibc 1.8.7 and 1.8.8 to v3.7 (LTS) so that the Zephyr LTS and the latest SDK 0.16.x Picolibc versions are in sync.

These questions are certainly something to think about.

While the C library is nominally a solid interface defined by the C language and POSIX standards, there are places (like this) where implementation details leak through. If there is a requirement that new versions of the SDK work against both the current development branch and LTS, then we better be testing (and fixing) code in all three places (LTS, main, SDK) instead of just working on Zephyr main and the SDK. Upleveling the toolchain would happen across all three trees at the same time.

That seems to go against my expectations for LTS; we're pulling in a fairly large code change without considering whether each patch meets the LTS goals. But, we also try to support a huge variety of (essentially untested) external toolchains, and this looks a lot like that in one sense.

Alternatively, we could weld the SDK and LTS versions together, supporting both in LTS fashion. That could be extended to other toolchains as well. There are toolchain-specific hacks throughout the Zephyr code base, presumably any of those could depend upon toolchain-version specific behavior.

I'm afraid I have no solid answers here, only questions.