Documenting macOS support across the project

[beriberikix]

Linux is the premiere development OS for Zephyr (for end users), with varying degrees of compatibility with macOS. I've been piecing together the gaps with the hope that it will help close those gaps in the future. Feedback and suggestions welcome!

Note: I only have an Intel machine to test; there's probably some things that may not work on Apple Silicon (ex. Qemu.)

Development

Feature	Intel	M1
west	✅	✅
net-tools	🚫1	🤔
mcumgr	✅	🤔

Build

Feature	Intel	M1
Manual	⚠️2	⚠️3
SDK	✅	✅
Docker	✅	🤔

Targets

Feature	Intel	M1
POSIX	🚫4	🚫4
QEMU	✅	✅

Tools

Feature	Intel	M1
Bluetooth tools	⚠️6	🤔

---

¹ See #15738
² Arm is well-supported by brew but other ARCHs may not be supported
³ Requires Rosetta
⁴ See #10945, #37123, #36140
⁵ Not all system working (x86 failed in recent tests); networking not supported via net-tools
⁶ Primary support via BlueZ; posix & QEMU support untested

[mbolivar-nordic]

West works on M1 (I have one, and I test).

[beriberikix]

Updated!

[mbolivar-nordic]

Manual build with GNU Arm Embedded on M1 also worked for me (I tested this last week). I had to install Rosetta 2, and I downloaded the 10-2020-q4-major release from the usual place, and then updated the permissions to allow Terminal to run the binaries from my developer settings as documented.

[beriberikix]

Got it. I made it a ⚠️ since it requires Rosetta and not a native (yet.)

[mbolivar-nordic]

I think there's an off-by-one in the footnote numbering.

[stephanosio]

FWIW, zephyrproject-rtos/crosstool-ng-old#25 should eventually address the SDK and QEMU support (+more) on macOS. In fact, I already have a working prototype featuring Homebrew packages for them.

Hopefully, I can get some traction on this in light of #36194.

[cfriedt]

SDK notes on macOS 11.4 / M1:

• Follow the crosstool-ng setup steps for macOS

  • https://crosstool-ng.github.io/docs/os-setup/

• version of bash shipped with macOS 11.4 is too old

  • brew install bash
  • export PATH="/opt/homebrew/Cellar/bash/5.1.8/bin:$PATH"

• missing required tool: gobjcopy objcopy

  • binutils should have been installed with the crosstool-ng setup steps
  • export PATH="/opt/homebrew/opt/binutils/bin:$PATH"

• configure: error: menu library not found

  • already installed - tried exporting CFLAGS and LDFLAGS but then crosstool-ng died complaining that I set CFLAGS
  • unset CFLAGS / LDFLAGS ... crosstool-ng goes on and then of course is building its own version of ncurses..
  • crosstool-ng dies at Building m4 which is already installed.

  I don't have a lot of time to continue debugging this. Has anyone else had some success?

[stephanosio]

You might have a better luck following the macOS-specific procedures here:
https://github.com/zephyrproject-rtos/crosstool-ng-old/blob/master-stephanos/.github/workflows/ci.yml

[stephanosio]

I just got an M1-based Mac Mini today and tested building sdk-ng on it -- building aarch64-zephyr-elf toolchain completed successfully without any issues. The rest should probably be fine too.

stephanos@devamac1:/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf/bin$ uname -a
Darwin devamac1.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64

stephanos@devamac1:/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf/bin$ ./aarch64-zephyr-elf-gcc -v
Using built-in specs.
COLLECT_GCC=./aarch64-zephyr-elf-gcc
COLLECT_LTO_WRAPPER=/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf/libexec/gcc/aarch64-zephyr-elf/10.3.0/lto-wrapper
Target: aarch64-zephyr-elf
Configured with: /Volumes/CrossToolNGNew/build/build_arm64/.build/aarch64-zephyr-elf/src/gcc/configure --build=aarch64-build_apple-darwin20.5.0 --host=aarch64-build_apple-darwin20.5.0 --target=aarch64-zephyr-elf --prefix=/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf --exec_prefix=/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf --with-local-prefix=/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf/aarch64-zephyr-elf --with-headers=/Volumes/CrossToolNGNew/build/output/aarch64-zephyr-elf/aarch64-zephyr-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.24.0.377_4d5660e' --enable-__cxa_atexit --disable-tm-clone-registry --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/Volumes/CrossToolNGNew/build/build_arm64/.build/aarch64-zephyr-elf/buildtools --with-mpfr=/Volumes/CrossToolNGNew/build/build_arm64/.build/aarch64-zephyr-elf/buildtools --with-mpc=/Volumes/CrossToolNGNew/build/build_arm64/.build/aarch64-zephyr-elf/buildtools --with-isl=/Volumes/CrossToolNGNew/build/build_arm64/.build/aarch64-zephyr-elf/buildtools --enable-lto --enable-target-optspace --disable-nls --enable-multiarch --enable-languages=c,c++ --with-gnu-ld --with-gnu-as --enable-initfini-array
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (crosstool-NG 1.24.0.377_4d5660e)

cc @galak

[cfriedt]

Would be very cool to support native_posix_64

[cfriedt]

Just thought I would link back here - #37123 provides a summary for native_posix_64 on macOS and brute-forces enough to get samples/hello_world to "work".

TL;DR - it's entirely possible (both on x86_64 and Aarch64 / M1).

Things main things needed to be done to make it work:

• Remove weak symbols from Zephyr (they are not supported with the Mach-O binary format and are not standard C)
• Change the way that we create and access ordered sections (Mach-O only allows section names with 1 <= n <= 16 chars)

W.r.t. weak symbols, we basically need to enforce some kind of singleton pattern. There are a few different ways to do that. One way is in #37435 where the singleton is enforced at link-time. I feel that Kconfig would be a good solution here because it offers the security of deciding the singleton at build-time but a with a level of convenience & control close to a runtime singleton.

W.r.t. section names, we currently define them mainly with the C Preprocessor. One proposal is to make that happen in CMake, which is discussed in #36140.