The xcframework build failed its own deployment-target guard on any Mac with
a Homebrew libopus installed:
ERROR: .../libpunktfunk_core.a contains objects built for macOS 26.0 (> 14.0)
The guard was right; its advice was not. This is not a stale cache, and the
suggested `rm -rf target/{aarch64,x86_64}-apple-darwin` never fixes it —
the objects come back on every clean rebuild.
audiopus_sys probes pkg-config before falling back to its vendored copy, and
on this machine it found /opt/homebrew/Cellar/opus/1.6.1 and linked it
statically. Homebrew compiles for the HOST macOS, so 143 SILK objects
(wrappers_FLP.o, VAD.o, stereo_*.o, resampler.o …) entered our staticlib
carrying minos 26 while everything we compiled carried 11 or 14.
That made a locally-built framework's validity depend on whether the
developer happens to have run `brew install opus` — for an artifact every
Apple build consumes and no one commits, which is exactly the kind of
environmental coupling that produces "works on my machine". OPUS_NO_PKG_CONFIG
forces the vendored build unconditionally; CMAKE_POLICY_VERSION_MINIMUM is
what that vendored copy needs to configure under CMake 4, which removed
support for the pre-3.5 minimum its CMakeLists still declares.
The guard's error message now names both causes and shows how to identify the
offending objects, since the misleading half cost real time.
Verified: from a fully clean target dir and with no environment variables set,
`bash scripts/build-xcframework.sh` completes and signs. `swift build` then
compiles PunktfunkKit, and `swift test --filter PresentIntervalsTests` runs
10/10 green — which pays off the Apple typecheck owed by d0d23994.
enricobuehler
e5ba78ea66