Doesn't work on Mac M1

[paulrouget]

Getting this error:

/pc_ble_driver_py/lib/macos_osx/libpc_ble_driver_shared_sd_api_v3.dylib: mach-o, but wrong architecture'.

[paulrouget]

It's possible to compile pc-ble-driver with the proper architecture with a few tweaks. But I'm not sure how to recompile pc-ble-driver-py to include the proper libraries.

[paulrouget]

I managed to package a python package that "kind of work".

It's missing this file:

pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex

How are these hex files packaged?

[jakezimmer]

It seems like this closed issue might have some relevant information:

https://github.com/NordicSemiconductor/pc-ble-driver-py/issues/57#issuecomment-408464618

[whodeenie]

I've been struggling with this too and have been trying to build everything from scratch. I think I've managed to build the underlying driver properly but the Python binding I'm still struggling with.

See here for the Dev Zone ticket.

It would be great to find out how to get past the packaging stage.

[whodeenie]

Hi Nordic, any word on when a native M1 build will be released? I currently have it working through Rosetta but it would be great to understand the roadmap.

[ShaharHD]

@whodeenie I did some of the leg work on this as well, and even created a PR (https://github.com/NordicSemiconductor/pc-ble-driver/pull/271) to simplify things... thought it might be worth sharing here as well:

As I even got nrf-util working as it should 🥇

If you're referrning to an M1 specifily here's my whole process:

1. Clone pc-ble-driver and apply the PR:

git clone https://github.com/NordicSemiconductor/pc-ble-driver.git --branch release/4.1.4
cd pc-ble-driver
git fetch origin pull/271/head:master
git checkout master

2. Build pc-ble-driver

mkdir build
cd build
cmake -G Ninja -DARCH=arm64 -DNRF_BLE_DRIVER_VERSION=4.1.4 -DCONNECTIVITY_VERSION=4.1.4 ..
cmake --build . # you can add -j8 if you want to push it :)
mkdir dist
cmake --install . --prefix dist

3. Go back up

   cd ..
   cd ..

now inside pc-ble-driver/build/dist you have the fully built pc-ble-driver which you can point to in any other project, like pc-ble-driver-py

4. Clone and build pc-ble-driver-py

   I tested only with brew python 3.9 (not with the mac builtin python version) make sure you have also have cmake installed

   
   git clone https://github.com/NordicSemiconductor/pc-ble-driver-py.git --branch release/0.16.2
   cd pc-ble-driver-py
   python3 -m venv venv
   source ./venv/bin/activate
   pip3 install --upgrade pip scikit-build
   pip3 install -r requirements-dev.txt

export CMAKE_PREFIX_PATH=$(pwd)/../pc-ble-driver/build/dist export MACOSX_DEPLOYMENT_TARGET=11.0 python3 setup.py bdist_wheel

To exit from the venv, simply `exit` from the terminal
> we have the venv to keep everything clean in the system

5. And here's the magic
Inside `pc-ble-driver-py/dist` you now have a `whl` file which is all you need for installing to any python3 (venv or not venv) and then you can even install `nrfutil` :)

```shell
pip3 install (workdir path from before)/pc-ble-driver-py/dist/pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl
pip3 install nrfutil # if you need this one as well, as pc-ble-driver-py is already satisfied, everything is good

[edglue]

@ShaharHD Thank you for this effort. I haven't yet had a chance to follow this through but will do soon and feedback to you.

[ShaharHD]

@ShaharHD Thank you for this effort. I haven't yet had a chance to follow this through but will do soon and feedback to you.

@edglue Nordic actually approved the PR (not merged yet) pretty quick. So hopefully it'll be merged in and released sometime in the near future.

But I got feedback from another person who had this issue and it resolved the issue for him.

[wiesener]

Any information about it, when it will be available from nordic?

[ShaharHD]

Any information about it, when it will be available from nordic?

@wiesener I'm afraid not. As I responed here https://github.com/NordicSemiconductor/pc-nrfutil/issues/361 you can see the respose from nordic here (no ETA any time soon)

https://github.com/NordicSemiconductor/pc-ble-driver/pull/271

[aryeko]

I see that NordicSemiconductor/pc-ble-driver#271 was merged 2 weeks ago. Any ETA for this package supporting apple silicon?

[ShaharHD]

I see that NordicSemiconductor/pc-ble-driver#271 was merged 2 weeks ago. Any ETA for this package supporting apple silicon?

Read my walkthrough - it'll give you a simple package you can install on any macOS

[aryeko]

I see that NordicSemiconductor/pc-ble-driver#271 was merged 2 weeks ago. Any ETA for this package supporting apple silicon?

Read my walkthrough - it'll give you a simple package you can install on any macOS

I was missing a key definition on cmake configuration files generation - ASIO_INCLUDE_DIR. I used the following command for configuration (instead on the one mentioned in step 2 of your walkthrough)

cmake -G Ninja -DARCH=arm64 -DNRF_BLE_DRIVER_VERSION=4.1.4 -DCONNECTIVITY_VERSION=4.1.4 -DASIO_INCLUDE_DIR=include/common ..

Build fails with the following:

[84/364] Building CXX object CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/sd_rpc_impl.cpp.o
FAILED: CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/sd_rpc_impl.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DASIO_STANDALONE -DHCI_LINK_CONTROL -DNRF_SD_BLE_API_VERSION=2 -DSD_RPC_EXPORTS -isystem ../src/sd_api_common/sdk/components/libraries/util -isystem ../src/sd_api_v2/sdk/components/serialization/application/codecs/common -isystem ../src/sd_api_v2/sdk/components/serialization/application/codecs/s130/serializers -isystem ../src/sd_api_v2/sdk/components/serialization/common -isystem ../src/sd_api_v2/sdk/components/serialization/common/struct_ser/s130 -isystem ../include/common -isystem ../include/common/internal -isystem ../include/common/internal/transport -isystem ../include/common/config -isystem ../include/common/sdk_compat -isystem ../include/sd_api_v2 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -fPIC -Wall -Wno-unknown-pragmas -Wno-undef -Wno-long-long -Wfloat-equal -Wpointer-arith -std=c++14 -m64 -std=gnu++14 -MD -MT CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/sd_rpc_impl.cpp.o -MF CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/sd_rpc_impl.cpp.o.d -o CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/sd_rpc_impl.cpp.o -c ../src/common/sd_rpc_impl.cpp
In file included from ../src/common/sd_rpc_impl.cpp:46:
../include/common/internal/transport/uart_settings_boost.h:43:10: fatal error: 'asio/serial_port.hpp' file not found
#include <asio/serial_port.hpp>
         ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[86/364] Building CXX object CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/common/app_ble_gap.cpp.o
../src/common/app_ble_gap.cpp:73:15: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct
              ^
               adapter_ble_gap_state_t
../src/common/app_ble_gap.cpp:76:65: note: type is not C-compatible due to this default member initializer
    ser_ble_gap_app_keyset_t app_keys_table[SER_MAX_CONNECTIONS]{};
                                                                ^~
../src/common/app_ble_gap.cpp:85:3: note: type is given name 'adapter_ble_gap_state_t' for linkage purposes by this typedef declaration
} adapter_ble_gap_state_t;
  ^
../src/common/app_ble_gap.cpp:99:15: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct
              ^
               adapter_codec_context_t
../src/common/app_ble_gap.cpp:105:21: note: type is not C-compatible due to this default member initializer
    void *adapter_id{nullptr};
                    ^~~~~~~~~
../src/common/app_ble_gap.cpp:118:3: note: type is given name 'adapter_codec_context_t' for linkage purposes by this typedef declaration
} adapter_codec_context_t;
  ^
2 warnings generated.
[93/364] Building CXX object CMakeFiles/nrf_ble_driver_obj_sd_api_v2.dir/src/sd_api_v2/ble_gap_impl.cpp.o
ninja: build stopped: subcommand failed.

[ShaharHD]

@aryeko you're not following all the prequisite steps for setting up the build enviroment from pc-ble-driver...

1. Install vcpkg - I would recommend installing the latest tag (2022.04.12)
2. Install vcpkg dependencies.

   # Make sure %VCPKG_ROOT% is set and added to %PATH%
   $ vcpkg install asio catch2 spdlog 

pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl.zip Attached the binary file in case it still fails, simply unzip and pip install

[knoandco]

@ShaharHD Thanks for the amazing step by step tutorial. I managed to go through as far as the part I need to build the pc-ble-driver-py. When I run : python3 setup.py bdist_wheel it fails. Here is the log I have : Undefined symbols for architecture arm64: "_libintl_bind_textdomain_codeset", referenced from: __locale_bind_textdomain_codeset in libpython3.10.a(_localemodule.o) "_libintl_bindtextdomain", referenced from: __locale_bindtextdomain in libpython3.10.a(_localemodule.o) "_libintl_dcgettext", referenced from: __locale_dcgettext in libpython3.10.a(_localemodule.o) "_libintl_dgettext", referenced from: __locale_dgettext in libpython3.10.a(_localemodule.o) "_libintl_gettext", referenced from: __locale_gettext in libpython3.10.a(_localemodule.o) "_libintl_setlocale", referenced from: __locale_setlocale in libpython3.10.a(_localemodule.o) __locale_localeconv in libpython3.10.a(_localemodule.o) "_libintl_textdomain", referenced from: __locale_textdomain in libpython3.10.a(_localemodule.o) ld: symbol(s) not found for architecture arm64 I believe I missed something stupid, but I am struggling here. I am running an M1 pro, with OS 12.3.1 installed. Would you have any idea on how to solve that linking issue ? best regards, David

[ShaharHD]

@knoandco try to add the following before running the python3 setup.py bdist_wheel

export LDFLAGS=-lintl

Building libraries like those on macOS usually involve setting up build enviroments using HomeBrew or similar. If you are still having issues, try to use the pre-compiled version I attached (one unzipped)

pip3 install pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl
pip3 install nrfutil

[knoandco]

Hi @ShaharHD, thanks for answering... I may have something corrupted... I already tried the attached package.. .but I have ERROR: pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl is not a supported wheel on this platform. I may have something really wrong. Also, nrf_util installed is 5.2 and not either the latest version nor a version that runs smoothly on my machine. Also I am running python 3.10.3...

[ShaharHD]

@knoandco Because cp39 is for Python 3.9 and you're running Python 3.10.x? which AFAIK nrfutil doesn't play nice with Python 3.10... and I'm also guessing you might have installed Python 3.10 for x64 and not arm64

So you might want to move back to Python 3.9 and make sure you install Python 3.9 arm64 verison.

I do not know what nerf_util is. There's nrfutil and nRF Command Line Tools

The latest nrfutil version is nrfutil version 6.1.3 - I do not know anything about v5.2

[knoandco]

@ShaharHD Right, I misspelled the nrf_util tool (my machine is still auto-correcting...). Using Python 3.9 solved magically all my issues. Thanks for your time and answers, D.

[wiesener]

Hi @ShaharHD, thanks for your support. I have a M1 too and I've installed python3.9 via brew which should be M1. At least the terminal which runs it is Apple and not Rosetta or Intel. I've tried to install your wheel but it still gives me ERROR: pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl is not a supported wheel on this platform. What am I missing? K

[ShaharHD]

@wiesener ... Nordic should be ashamed it's been over two years now and still no proper support for Apple Silicon on such a basic tool required for development.

I'm guessing you are running a different version of python... do the following verify your python environment and post it back:

pip3 --version
python3 --version
file $(which python3)

[wiesener]

% pip3 --version pip 22.2.2 from /opt/homebrew/lib/python3.9/site-packages/pip (python 3.9) % file $(which python3) /opt/homebrew/Cellar/python@3.9/3.9.13_4/libexec/bin/python3: Mach-O 64-bit executable arm64

[ShaharHD]

% pip3 --version pip 22.2.2 from /opt/homebrew/lib/python3.9/site-packages/pip (python 3.9) % file $(which python3) /opt/homebrew/Cellar/python@3.9/3.9.13_4/libexec/bin/python3: Mach-O 64-bit executable arm64

Are you on Monterey (macosx_12_0_arm64) or BigSur (macosx_11_0_arm64) ? If Monterey, you'll need to follow the howto and compile it again for v12 probably.

Make sure to change MACOSX_DEPLOYMENT_TARGET to export MACOSX_DEPLOYMENT_TARGET=12.0 and update all the references as pc-nrfutil version 6.1.6 now exists

Also worth mentioning my Pull Request on pc-ble-driver is now merged into the repo, so no need to apply it.

Built it for you - try this pc_ble_driver_py-0.17.0-cp310-cp310-macosx_12_0_arm64.whl.zip

[nehalkpatel]

I am able to follow the instructions above and build pc_ble_driver_py-0.17.0-cp39-cp39-macosx_11_0_arm64.whl; however I get a segfault when trying to load the driver. Following similar instructions on Linux x86_64 it loads without issue. Wondering if anyone else is having similar issues; I'm wondering if this is more related to swig than this library? It also fails when I use the pre-built pc_ble_driver_py-0.16.2-cp39-cp39-macosx_11_0_arm64.whl attached above.

python3 -c 'from pc_ble_driver_py import config; config.__conn_ic_id__ = "NRF51"; from pc_ble_driver_py import ble_driver as nrf_ble_driver'
[1]    9346 segmentation fault  python3 -c 

❯ lldb --  python3 -c 'from pc_ble_driver_py.lib import nrf_ble_driver_sd_api_v5 as driver'
(lldb) target create "python3"
Current executable set to 'python3' (arm64).
(lldb) settings set -- target.run-args  "-c" "from pc_ble_driver_py.lib import nrf_ble_driver_sd_api_v5 as driver"
(lldb) run
Process 9642 launched: '/Users/nehalpatel/tools/pc-ble-driver-py/venv/bin/python3' (arm64)
Process 9642 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x0000000105b21cd8 _nrf_ble_driver_sd_api_v5.so`_PyObject_GC_Alloc(use_calloc=0, basicsize=48) at gcmodule.c:0 [opt]
Note: this address is compiler-generated code in function _PyObject_GC_Alloc that has no source code associated with it.
Target 0: (python3) stopped.
warning: _nrf_ble_driver_sd_api_v5.so was compiled with optimization - stepping may behave oddly; variables may not be available.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
  * frame #0: 0x0000000105b21cd8 _nrf_ble_driver_sd_api_v5.so`_PyObject_GC_Alloc(use_calloc=0, basicsize=48) at gcmodule.c:0 [opt]
    frame #1: 0x0000000105b21e90 _nrf_ble_driver_sd_api_v5.so`_PyObject_GC_New [inlined] _PyObject_GC_Malloc(basicsize=<unavailable>) at gcmodule.c:2294:12 [opt]
    frame #2: 0x0000000105b21e88 _nrf_ble_driver_sd_api_v5.so`_PyObject_GC_New(tp=0x0000000105cbd920) at gcmodule.c:2306:20 [opt]
    frame #3: 0x0000000105a14574 _nrf_ble_driver_sd_api_v5.so`PyDict_New [inlined] new_dict(keys=<unavailable>, values=<unavailable>) at dictobject.c:628:14 [opt]
    frame #4: 0x0000000105a14538 _nrf_ble_driver_sd_api_v5.so`PyDict_New at dictobject.c:723:12 [opt]
    frame #5: 0x0000000105774e14 _nrf_ble_driver_sd_api_v5.so`PyInit__nrf_ble_driver_sd_api_v5 + 38444
    frame #6: 0x000000010014d0d4 python3`_PyImport_LoadDynamicModuleWithSpec + 640
    frame #7: 0x000000010014c8e8 python3`_imp_create_dynamic + 444
...
    frame #85: 0x0000000100181a40 python3`pymain_main + 324
    frame #86: 0x0000000100181ae0 python3`Py_BytesMain + 40
    frame #87: 0x00000001003b508c dyld`start + 520

[ShaharHD]

@nehalkpatel I would follow up with Nordic about this. They seems to simply not care about Apple Silicon at this moment...

[wiesener]

Okay as you can see in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/91553/nrfutil-not-working-on-m1 Nordic is going to stop the development of https://pypi.org/project/pc-ble-driver-py. Therefore, I've checked https://github.com/NordicSemiconductor/pc-nrfutil/releases/tag/v6.1.6 and downloaded the mac executable. You then need to uninstall nrfutil from python and make the new executable a executable via chmod and create a symbolic link. Then you can use it as normal with all features. I guess internally it will use the rosetta emulation but at least it works.

[ShaharHD]

Okay as you can see in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/91553/nrfutil-not-working-on-m1 Nordic is going to stop the development of https://pypi.org/project/pc-ble-driver-py. Therefore, I've checked https://github.com/NordicSemiconductor/pc-nrfutil/releases/tag/v6.1.6 and downloaded the mac executable. You then need to uninstall nrfutil from python and make the new executable a executable via chmod and create a symbolic link. Then you can use it as normal with all features. I guess internally it will use the rosetta emulation but at least it works.

Nordic has decided to abandon all nRF5-SDK related projects as they focus only on nRF Connect SDK (which is a shame IMHO). NCS is not the optimal choice for everything (especially with small SoC like the nRF52805 or nRF52810)

Just ranting here, and I'm guessting it will not change anything on Nordic end, but this workaround will work for a while, but usually when you start to have those workaround, based on my personal experience is when things start to break because of incomptabilty.

@nehalkpatel did you resolve it in the end? I had the issue on another apple silicon mac, we just went back to the same version which was the latest one when this thread has started, and everything worked

[nehalkpatel]

Nope. M1 won't run. So I basically have a dummy, broken package for now and tell people to use x86 or Linux instead.

[ShaharHD]

Nope. M1 won't run. So I basically have a dummy, broken package for now and tell people to use x86 or Linux instead.

sorry to hear that, I'm guessing there's something unique about your system. In any case, you can follow @wiesener approach and it should resolve the issue for you for now.