Open cfriedt opened 4 months ago
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).
Marking it as an enhancement instead of a bug since 0.16.7 has been released without the C11 threads-based gthread libgcc patch.
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.
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_GLOBALN_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_cxx6cond9broadcastEv[_ZN9gnu_cxx6cond9broadcastEv]+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.
Hi, I'm facing the same issue as @markaj-nordic mentioned. Any progress of instructions to solve this issue? Tnx
@seyednasermoravej use 0.16.8
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.
One possible solution for the above would be to create weak versions of the C11 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
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