missing --start-group around WBA2_LinkLayer_BLE_Full_lib.
Environment
- STM32CubeMX version: 6.17.0
- STM32CubeWBA firmware package: 1.9.0
- Target device: STM32WBA25CG (NUCLEO-48 board)
- Toolchain: GNU Tools for STM32 14.3.1+st.2 (arm-none-eabi-gcc/ld)
- Build system: CMake (toolchain selected via "CMake" in CubeMX project settings)
- Host OS: Windows 11
Steps to reproduce
- Create a new STM32CubeMX project for STM32WBA25 (NUCLEO board).
- Enable BLE (peripheral role, BLE_Full stack).
- In Project Manager → Toolchain/IDE, select CMake.
- Generate code.
- Build with the generated CMakeLists (e.g. cube-cmake --build build/Debug).
Expected Build links cleanly.
Actual Link fails with:
ld.exe: stm32wba_ble_stack_full.a(le_ctrl.o): in function `LECTRL_LL_Init':
le_ctrl.c:(.text.LECTRL_LL_Init+0xa): undefined reference to `ll_ble_events_init'
ld.exe: (ll_ble_events_init): Unknown destination type (ARM/Thumb) in
stm32wba_ble_stack_full.a(le_ctrl.o)
le_ctrl.c:(.text.LECTRL_LL_Init+0xa): dangerous relocation: unsupported relocation
Root cause The generated cmake/stm32cubemx/CMakeLists.txt emits the BLE archives in this order in MX_LINK_LIBS:
set(MX_LINK_LIBS
:WBA2_LinkLayer_BLE_Full_lib.a
:stm32wba_ble_stack_full.a
...
)which produces the link line:
... -l:WBA2_LinkLayer_BLE_Full_lib.a -l:stm32wba_ble_stack_full.a -lm
The two archives are mutually dependent:
- stm32wba_ble_stack_full.a (le_ctrl.o) → LECTRL_LL_Init → references ll_ble_events_init
- WBA2_LinkLayer_BLE_Full_lib.a (ll_ble_events.o) → defines ll_ble_events_init → references ll_sys_ble_cntrl_init (defined in project sources / ll_sys_startup.c)
GNU ld only scans static archives in the order they appear and does not re-scan earlier archives by default. When stm32wba_ble_stack_full.a is processed and pulls in le_ctrl.o, the new undefined reference to ll_ble_events_init cannot be resolved because the link-layer archive has already been scanned. The follow-up Unknown destination type (ARM/Thumb) is a secondary error from ld attempting to emit an interworking veneer to a still-unresolved symbol.
I confirmed ll_ble_events_init is present and defined in WBA2_LinkLayer_BLE_Full_lib.a (arm-none-eabi-nm shows T ll_ble_events_init, size 8 bytes — a small Thumb-2 trampoline into ll_sys_ble_cntrl_init). So this is purely a link-ordering bug, not a missing-library issue.
Suggested fix in the CubeMX CMake template Wrap the two BLE archives in --start-group/--end-group so ld re-scans until all references are resolved:
set(MX_LINK_LIBS
-Wl,--start-group
:WBA2_LinkLayer_BLE_Full_lib.a
:stm32wba_ble_stack_full.a
-Wl,--end-group
STM32_Drivers
${TOOLCHAIN_LINK_LIBRARIES}
Utilities STM32_WPAN Common
)(Or, for CMake ≥ 3.24, use $<LINK_GROUP:RESCAN,...>.) Simply swapping the order works for this specific symbol chain too, but the group is robust against any future circular dependency between the link-layer and BLE-stack archives. The IAR/MDK/Makefile templates appear unaffected because of how they emit the link command.
Workaround Manually edit cmake/stm32cubemx/CMakeLists.txt after each regeneration to add the --start-group/--end-group flags.
