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.md
 
Thanks for your time, and for the project.
 
Andrei Gosman