NCS 3.3.0: CMake configure hangs at arm-zephyr-eabi-gdb-py --configuration during sysbuild on macOS

[nrbrook]

Hi Nordic team,

I’m seeing a repeatable configure hang with NCS v3.3.0 sysbuild on macOS. The visible build output stops after:

-- Found GnuLd: .../arm-zephyr-eabi/bin/ld.bfd (found version "2.38")

After inspecting the process tree, CMake is blocked waiting on:

.../opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb-py --configuration

The arm-zephyr-eabi-gdb-py process sits indefinitely in uninterruptible wait (U state), and the parent CMake process never continues.

Environment:

• macOS 15.6 / Darwin 24.6.0
• NCS v3.3.0
• Zephyr 4.3.99
• Sysbuild enabled

The hang happens during the inner application CMake configure launched by sysbuild.

I tried passing this workaround:

-DCMAKE_GDB=/usr/bin/false

That works for non-sysbuild builds, but with sysbuild it does not reliably solve the issue because the inner application configure does not inherit CMAKE_GDB from the top-level sysbuild configure.

I added a timeout to the command in zephyr (zephyr/cmake/bintools/gnu/target.cmake line 21):

if(CMAKE_GDB)
  execute_process(
    COMMAND ${CMAKE_GDB} --configuration
    TIMEOUT 5
    RESULTS_VARIABLE GDB_CFG_ERR
    OUTPUT_QUIET
    ERROR_QUIET
    )
endif()

This falls back to arm-zephyr-eabi-gdb when arm-zephyr-eabi-gdb-py times out.

Questions:

• Is this a known issue with arm-zephyr-eabi-gdb-py --configuration on macOS?
• Is there a recommended way to disable or override the GDB probe for sysbuild inner image configures?
• Should sysbuild propagate CMAKE_GDB to the application image, or is there another supported cache variable for this?

[nrbrook]

I did some more debugging and found what looks like the underlying cause.

`arm-zephyr-eabi-gdb-py` is linked against an absolute Homebrew Python 3.10 framework path:

/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.10/Python

This is visible with:

otool -L /opt/nordic/ncs/toolchains/185bb0e3b6/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb-py

On my machine that path does not exist anymore. I only have newer Homebrew Python versions installed. Plain `arm-zephyr-eabi-gdb` does not have this dependency.

Sampling the stuck `arm-zephyr-eabi-gdb-py` process shows that it never reaches GDB code. It is stopped in dyld during process startup:

dyld4::halt
abort_with_payload
__abort_with_payload

Sampling the parent CMake process shows it is blocked in CMake’s `execute_process()` implementation waiting for the child process:

cmExecuteProcessCommand
cmsysProcess_WaitForData
__select

So this appears to be a toolchain packaging issue: the Python-enabled GDB binary has an absolute runtime dependency on `/opt/homebrew/opt/[email protected]`, but that dependency is not provided by the Nordic toolchain and is not part of the NCS toolchain Python installation.

This also explains why the timeout workaround fixes the configure: when the `gdb-py --configuration` probe times out, Zephyr falls back to plain `arm-zephyr-eabi-gdb`, which does not require Homebrew Python 3.10.

Could Nordic confirm whether `arm-zephyr-eabi-gdb-py` is expected to depend on a user-installed Homebrew `[email protected]`? If not, it seems like the macOS toolchain should either vendor/relocate that Python framework dependency, use an `@rpath`/toolchain-local dependency, or avoid probing `gdb-py` without a timeout.