Hello,

I have put together a working port of libosmocore for macOS on Apple Silicon (M1/M2/M3/M4), and I would like guidance on whether the Osmocom project would consider accepting it upstream, and if so, in what form.

Current state, published as a standalone fork:

https://github.com/AndreiGosman/libosmocore-macos-arm64

The port enables native compilation and runtime of libosmocore and its submodules (libosmovty, libosmocodec, libosmogsm, libosmocoding, libosmoisdn) on Darwin/ARM64. On top of it I have gr-gsm building and running natively, with grgsm_decode functional on IQ captures from a LibreSDR B220 Mini via UHD. The rest of the stack (grgsm_scanner, grgsm_livemon, gr-osmosdr) is not yet addressed.

The current patchset is pragmatic rather than idiomatic. Approach:

- Six files that include Linux-only headers or use Linux-only APIs (linux/if.h, linux/tcp.h, cpu_set_t + sched_setaffinity, linux/if_tun.h) are wrapped whole in #ifdef __linux__: cpu_sched_vty, netdev, serial, stats_tcp, tun, gprs_ns2_fr.

- A new src/core/darwin_stubs.c exports no-op public symbols for the wrapped files (osmo_tcp_stats_config, osmo_stats_tcp_*, osmo_timerfd_*, osmo_tundev_*), so consumers link cleanly on Darwin.

- A darwin_compat.h is included via CFLAGS -include and provides dummy values for SO_PRIORITY, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME, plus a gettid() alias to getpid().

- src/core/exec.c sed-patched to substitute setresgid/setresuid (Linux) with setregid/setreuid (Darwin) for the specific 3-arg-equal use case.

- configure invoked with --disable-uring --disable-libmnl --disable-libsctp.

- LDFLAGS "-Wl,-undefined,dynamic_lookup" applied at make only, not at configure (to avoid false-positive detection of gettid/setns/unshare).

I am aware this shape is unlikely to be acceptable as-is: whole-file wrapping is coarse, the compat header injection through CFLAGS bypasses your feature-detection model, and stubs that unconditionally return NULL/-1 have degraded semantics for real callers.

My question: would upstream accept a refactored version of this? And if yes, in what shape:

(1) Inline per-function or per-block #ifdef __linux__ conditionals within the existing files (no wraps, no separate stubs file).

(2) Autoconf feature detection (AC_CHECK_HEADERS / AC_CHECK_FUNCS) with HAVE_* macros driving conditional compilation in .c files, and a proper compat header included from public headers rather than via -include.

(3) A combination: (2) for portable features, (1) with clear comments for the rest, and darwin_stubs.c kept as a small explicit file referenced from Makefile.am rather than added implicitly.

If any of the above is acceptable, I am willing to invest the time to refactor, submit via Gerrit, and iterate on review. If macOS support is out of scope for the project by policy, I will keep the fork as a standalone resource for the Mac community and close this thread.

Testing environment for the current patchset:

- macOS Tahoe (Darwin 25.5.0), Apple Silicon M4 - Homebrew 6.0.21, GNU Radio 3.10.12, Python 3.14 - libosmocore tag 1.14.2.4-2a26b

Full patch details and rationale are in the fork README:

https://github.com/AndreiGosman/libosmocore-macos-arm64/blob/master/README.m...

Thanks for your time, and for the project.

Andrei Gosman