Skip to content

Drop allow_macos_failure now that the macOS segfault is fixed - #70

Merged
ryanmrichard merged 3 commits into
masterfrom
fix/revert-macos-diagnostics-pin
Aug 12, 2026
Merged

Drop allow_macos_failure now that the macOS segfault is fixed#70
ryanmrichard merged 3 commits into
masterfrom
fix/revert-macos-diagnostics-pin

Conversation

@ryanmrichard

Copy link
Copy Markdown
Member

Summary

  • The macOS-only pybind11 module segfault tracked in scf-macos-pybind11-segfault.md is fixed upstream via NWChemEx/.github#189 (Python_FIND_STRATEGY=LOCATION), already merged.
  • Verified via a throwaway diagnostics PR ([throwaway] macOS dyld Python-runtime diagnostics (DO NOT MERGE) #68, closed): 4/4 tests passing on both macos-14 compiler legs (clang-18, gcc-14), including the C++ binaries that embed their own Python interpreter.
  • Drops the allow_macos_failure: "true" workaround (added in #188) from both pull_request.yaml and nightly.yaml so macOS is a real merge-blocking signal again, same as every other platform/job.

Test plan

  • CI on this PR itself should now show macOS test_cmake_build/test_pip_build passing normally (not just running-but-ignored).

🤖 Generated with Claude Code

The macOS pybind11 module segfault (scf-macos-pybind11-segfault.md) is
fixed upstream via NWChemEx/.github#189 (Python_FIND_STRATEGY=LOCATION),
verified 4/4 passing on both compiler legs. macOS should now be a real
merge-blocking signal like every other platform/job.
test_pip_build's macOS gcc-14 leg fails deterministically for an
unrelated, pre-existing reason (meson can't detect Homebrew gcc-14's
linker while building numpy from source -- "Unable to detect linker
for compiler `gcc-14 -Wl,--version`"), not the pybind11 segfault fixed
by NWChemEx/.github#189. That fix only touches test_cmake_build's
Configure step, so dropping allow_macos_failure from test_pip_build too
was premature -- confirmed via this PR's own CI, which surfaced the
gcc-14 failure again once unmasked. Keeping it dropped for
test_cmake_build, which is genuinely fixed and verified (4/4 tests
passing on both compiler legs).
numpy<2 was capped unconditionally to work around a manylinux2014/GCC-ABI
constraint that only exists on Linux. On macOS it had the opposite effect:
numpy<2's newest release (1.26.4) has no cp314 wheel, so pip fell back to
building it from source, which fails distinctly there -- Homebrew's gcc-14
has no bundled linker and shells out to Apple's system ld, and meson's
linker-detection probe (`gcc-14 -Wl,--version`) doesn't understand current
macOS/Xcode's linker ("ld: unknown options: --version"). That's the
test_pip_build (macos-14, gcc-14) failure allow_macos_failure has been
masking.

Scope the cap to sys_platform == 'linux' via a PEP 508 marker and leave
macOS unconstrained, so it resolves a real numpy>=2 wheel instead of
falling back to a source build at all -- sidesteps the linker-probe issue
entirely rather than working around it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@ryanmrichard
ryanmrichard merged commit 9d4d7d1 into master Aug 12, 2026
23 of 25 checks passed
@ryanmrichard
ryanmrichard deleted the fix/revert-macos-diagnostics-pin branch August 12, 2026 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant