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

[pdgendt]

Zephyr version as of writing: zephyrproject-rtos/zephyr@53738cf
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 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.

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.

[stephanosio]

After giving this more thought, I think we should indeed keep the Picolibc version for the SDK 0.16.9 at what is used by the Zephyr LTS3 (v3.7).

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.

Indeed, we would want a companion SDK LTS release that goes with a Zephyr LTS release.

I will make the SDK compatibility level 0.16 (0.16.x release) an LTS and keep the changes, including the Picolibc version, in 0.16.x compatible with Zephyr LTS3.

we better be testing (and fixing) code in all three places (LTS, main, SDK) instead of just working on Zephyr main and the SDK

Yes, I will create v0.16-branch, which will be the SDK LTS branch, and update the CI workflow to run tests against Zephyr v3.7-branch.

[keith-packard]

To meet the picolibc integration guidelines, we still need an SDK branch with the same picolibc version as is on Zephyr main. Are you thinking that would be SDK 0.17.x?

[stephanosio]

To meet the picolibc integration guidelines, we still need an SDK branch with the same picolibc version as is on Zephyr main. Are you thinking that would be SDK 0.17.x?

Yes, I will be releasing the SDK 0.17.0 with Picolibc 1.8.8 alongside the SDK 0.16.9 with Picolibc 1.8.6 this time.

[otavio]

Wouldn't it be simpler to synchronize the versioning with the project?

We would release an SDK 3.7.x. The development branch would necessarily release a 4.0.0-alpha or similar until the project's final release.

I think the version does not map directly to the compatibility with the project, which might not be very clear. So, specifically for people who are not that involved with the project, that might cause problems and disappointments

[stephanosio]

Wouldn't it be simpler to synchronize the versioning with the project?

It would be simpler, but very inefficient and expensive because we then have to make new "revision" releases for all previous supported Zephyr SDK releases even for small compatible changes.

For example, let us say we have SDK 3.4.0, 3.5.0 and 3.6.0 that can be used with Zephyr 3.4, 3.5 and 3.6, respectively. Whenever there is a small non-breaking change, we have to release 3.4.1, 3.5.1 and 3.6.1 with the scheme you propose; whereas, with the current scheme, they will be on the same "compatibility level" (say 0.16) and we only need to release SDK 0.16.1.

Given the expensiveness of the SDK CI and the time required to make and test releases, I am afraid this is not feasible.

For previous discussions on the versioning scheme, please see #608.