Fix #39: x64 macOS deps + app target Monterey (12.0)#40
Merged
Conversation
…sue #39) Deps built on macos-15 default to minos 15.0, so vspipe-bin and the from-source plugins link libc++/libSystem symbols absent on Monterey, causing the "dyld: Symbol not found" crash reported in #39. Pin MACOSX_DEPLOYMENT_TARGET=12.0 for the x64/Intel build only (arm64 is left unchanged — its hardware floor is Big Sur and there is no old arm64 runner). This retargets everything built from source. A new minos verification pass walks every bundled Mach-O and reports anything still newer than the target; it warns by default (STRICT_MIN_OS=1 to fail) so the first CI run surfaces the prebuilt artifacts (Homebrew bottles, ffmpeg, Python) that env-var retargeting can't reach. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…rey (issue #39) Building vspipe against the new 12.0 target fails to compile: 'to_chars is unavailable: introduced in macOS 13.3' because doubleToString() in src/vspipe/{vsjson,vspipe}.cpp uses the floating-point std::to_chars, whose libc++ implementation only exists on 13.3+. That same symbol is what Monterey's dyld couldn't resolve in #39. Rewrite doubleToString() to emit the shortest round-tripping fixed-notation string via snprintf (verified byte-identical to to_chars fixed across whole numbers, repeating decimals, and the 23.976/29.97/59.94 fps cases). Applied x64-only so the arm64 bundle is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Abandon the Monterey/12.0 deployment-target approach (it required source- building the Homebrew support libs, incl. an ABI-sensitive boost). Instead set the floor at macOS 13 the simple way: build the x64 deps on the macos-13 runner, so `brew install` pours Ventura bottles and clang defaults to a macOS 13 target. The whole x64 bundle then loads on macOS 13+. Note: this does not help the original #39 reporter on Monterey 12.7.6 — 13 is the new minimum. arm64 is unchanged (still macos-15). Reverts the exploratory deployment-target pin / vspipe patch / minos guard from earlier commits on this branch; download-deps-macos.sh is back to main apart from the runner note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…c 2025) macos-13 is no longer a valid hosted runner label (jobs hang queued forever). The only Intel runner is macos-15-intel. Reverting to keep the deps workflow working; lowering the x64 floor needs the source-build approach instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…sue #39) The only hosted Intel runner is macos-15-intel (macos-13 was retired), where brew pours minos 14/15 bottles that won't load on macOS 12. So build the five bundled support libraries from source with MACOSX_DEPLOYMENT_TARGET=12.0: - xz/liblzma 5.4.6, fftw 3.3.10 (float+threads), zimg 3.0.5, libdvdread 6.1.3 -> stable C ABIs, dropped in over the Homebrew copies before the repoint pass - boost 1.85.0 (filesystem, atomic) -> ABI-sensitive, so nnedi3cl/knlmeanscl are now compiled against it via BOOST_ROOT="$SRCLIB" Combined with the deployment-target pin + the vspipe std::to_chars patch (restored), the whole x64 bundle now targets macOS 12. The minos guard runs with STRICT_MIN_OS=1 in CI so the build fails if anything still exceeds 12.0. arm64 is untouched (the entire block is x86_64-gated). All five build recipes validated locally (correct dylib names + @rpath ids). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The x64 deps now target macOS 12; pin the app shell + Rust worker to match so the app launches on Monterey. Sets MACOSX_DEPLOYMENT_TARGET=12.0 in the build workflow (rustc reads it for the worker), the Xcode project (Runner, 3 configs), and the Podfile platform. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Lets us produce signed-but-un-notarized DMGs for local testing when the Apple notary agreement is unavailable. Default stays true for real releases. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…4 test) Un-gate the deployment-target pin, vspipe to_chars patch, source-built support libs, override copies, and minos guard to run on arm64 as well as x64. arm64 now also targets macOS 12.0 and bundles source-built zimg/fftw/dvdread/xz/boost. Recon step: the arm64 prebuilt plugins (yuygfgg neo-f3kdb/dfttest/ttempsmooth/ fft3dfilter/vivtc, Stefan-Olt tmedian/bestsource) are NOT yet source-built, and arm64 nnedi3cl/knlmeanscl still link Homebrew boost. The guard runs in warning mode on arm64 (STRICT_MIN_OS unset for that job) to report what remains >12. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
arm64 test)" This reverts commit 8d11cc5.
Lets a manual run target just macOS (both arches), Windows, or Linux instead of always fanning out to all four. Scheduled (cron) runs are unaffected — they still run everything. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…IN_OS) (issue #39) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves the macOS Monterey "dyld: Symbol not found" crash in #39 for Intel/x64.
Root cause
x64 deps were built on a Sequoia runner with no deployment target, so
vspipe-binand bundled dylibs wereminos 15and linked symbols (e.g.std::to_chars(double), libc++ 13.3+) absent on macOS 12.What changed (x64 only — arm64 is byte-for-byte unchanged)
MACOSX_DEPLOYMENT_TARGET=12.0for the x64 deps build.minos 14/15). Needed because the only hosted Intel runner ismacos-15-intel(macos-13is retired).nnedi3cl/knlmeanscl) against the source boost (BOOST_ROOT) for ABI match.doubleToStringoffstd::to_chars(snprintf, verified byte-identical output).STRICT_MIN_OS=1inbuild-deps-macos.ymlfails the build if any bundled Mach-O exceeds 12.0.build-macos.yml, Runner.xcodeproj, Podfile); add an optionalnotarizeinput tobuild-macos.ymland aplatformfilter tonightly.yml.Validation
STRICT_MIN_OS=1— every bundled binary ≤ 12.0.deps-v1.6.0.v0.9.9).arm64 stays at
minos 15(no old runner; prebuilt arm64 plugins are >12) — see #39 discussion.🤖 Generated with Claude Code