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

nrbrook — Wed, 06 May 2026 11:24:19 GMT

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/python@3.10/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/python@3.10`, 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 `python@3.10`? 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.