libgcc: C11 threads-based gthread support cannot link samples/cpp/hello_world out-of-the-box

[cfriedt]

trafficstars

Just test-driving the v0.16.6 SDK, and it looks like samples/cpp/hello_world does not build and run OOTB.

Moving from v0.16.5-1 to 0.16.6, I needed to additionally enable the following in order for the app to link.

CONFIG_COMMON_LIBC_THRD=y
CONFIG_POSIX_API=y
CONFIG_DYNAMIC_THREAD=y
CONFIG_THREAD_STACK_INFO=y

One possible solution for the above would be to create weak versions of the C11 <thread.h> functions in the toolchain, such that linking to an external implementation will provided the necessary functionality (when required).

Since samples/cpp/hello_world does not require C++11 threading, this seems like it would be a good choice.

Beyond that, a couple of additional platforms are now facing issues

qemu_riscv64 and qemu_riscv32

[142/143] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv64
*** Booting Zephyr OS build v3.6.0-3273-g40a8022e4a14 ***
abort()

[142/143] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv32
*** Booting Zephyr OS build v3.6.0-3273-g40a8022e4a14 ***
abort()

This is likely due to something like stack unwinding, but it will take additional effort to diagnose / remedy.

Otherwise, qemu_x86_64, qemu_cortex_a53, qemu_cortex_m3 have been tested with the command below

west build -p -b qemu_cortex_m3 -t run samples/cpp/hello_world \
  -- \
  -DCONFIG_COMMON_LIBC_THRD=y \
  -DCONFIG_POSIX_API=y \
  -DCONFIG_DYNAMIC_THREAD=y \
  -DCONFIG_THREAD_STACK_INFO=y

[stephanosio]

This effectively renders the SDK 0.16.6 release unusable until the C11 threads stub functions are added to the Zephyr main branch.

Also, this is a breaking change that creates an incompatibility between the SDK 0.16.6 release and any Zephyr releases prior to the upcoming 3.7.0, which we do not want at this point.

This should have been caught earlier and addressed in a more self-contained way within the SDK (e.g. providing weak C11 threads stub functions within the libgcc itself); unfortunately, the SDK CI does not build and run the C++ tests and samples and this was not caught -- I am going to fix that by adding more tests to be run in the SDK CI.

At this point, I will need to mark the 0.16.6 a bad release and release 0.16.7 without the libstdc++ C11 gthread patch. The libstdc++ patch will need to be reworked to handle the transition more gracefully (as mentioned above, by providing weak C11 threads stubs).

[stephanosio]

Marking it as an enhancement instead of a bug since 0.16.7 has been released without the C11 threads-based gthread libgcc patch.

[cfriedt]

This effectively renders the SDK 0.16.6 release unusable until the C11 threads stub functions are added to the Zephyr main branch.

We likely do not want stub or weak implementations in Zephyr itself since there is a concrete implementation already.

Also, this is a breaking change that creates an incompatibility between the SDK 0.16.6 release and any Zephyr releases prior to the upcoming 3.7.0, which we do not want at this point.

I would definitely prefer to get this in prior to v3.7.0, since it's already been ~ 2 LTS release cycles in the making.

This should have been caught earlier and addressed in a more self-contained way within the SDK (e.g. providing weak C11 threads stub functions within the libgcc itself); unfortunately, the SDK CI does not build and run the C++ tests and samples and this was not caught -- I am going to fix that by adding more tests to be run in the SDK CI.

Agreed and good idea.

[markaj-nordic]

FYI: After switching to the 0.16.6, without any tweaks, our C++ Matter applications won't build (due to the linkage issue):

/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::init_static_cond()': guard.cc:(.text._ZN12_GLOBAL__N_1L16init_static_condEv+0x6): undefined reference to cnd_init' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::init()': guard.cc:(.text._ZN12_GLOBAL__N_1L4initEv+0x8): undefined reference to mtx_init' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::mutex_wrapper::~mutex_wrapper() [clone .isra.0]': guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperD2Ev.isra.0+0xa): undefined reference to mtx_unlock' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::mutex_wrapper::mutex_wrapper() [clone .isra.0]': guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperC2Ev.isra.0+0xa): undefined reference to call_once' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperC2Ev.isra.0+0x12): undefined reference to mtx_lock' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __gnu_cxx::__cond::broadcast()': guard.cc:(.text._ZN9__gnu_cxx6__cond9broadcastEv[_ZN9__gnu_cxx6__cond9broadcastEv]+0x2): undefined reference to cnd_broadcast' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __cxa_guard_acquire': guard.cc:(.text.__cxa_guard_acquire+0x2c): undefined reference to call_once' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text.__cxa_guard_acquire+0x36): undefined reference to call_once' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text.__cxa_guard_acquire+0x40): undefined reference to cnd_wait' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __cxa_guard_release': guard.cc:(.text.__cxa_guard_release+0x1a): undefined reference to `call_once'

Any ETA for 0.16.7 release? I see the tag is already there.

[seyednasermoravej]

Hi, I'm facing the same issue as @markaj-nordic mentioned. Any progress of instructions to solve this issue? Tnx

[cfriedt]

@seyednasermoravej use 0.16.8