From 6d15adea7602ee9388c1ddf83c1850233ca278d4 Mon Sep 17 00:00:00 2001 From: "Ryan M. Richard" Date: Tue, 11 Aug 2026 14:12:29 -0500 Subject: [PATCH 1/3] Drop allow_macos_failure now that the macOS segfault is fixed 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. --- .github/workflows/nightly.yaml | 4 ---- .github/workflows/pull_request.yaml | 7 ------- 2 files changed, 11 deletions(-) diff --git a/.github/workflows/nightly.yaml b/.github/workflows/nightly.yaml index 81a2fff..769bc1e 100644 --- a/.github/workflows/nightly.yaml +++ b/.github/workflows/nightly.yaml @@ -24,7 +24,6 @@ on: - cron: "0 6 * * *" # Every day at 06:00 UTC (00:00 CST) jobs: - # allow_macos_failure: see pull_request.yaml's comment on the same input. test_cmake_build: uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master with: @@ -32,9 +31,6 @@ jobs: cmake_opts: "-DINTEGRATION_TESTING=ON" python_version: "3.12" extra_pip_packages: "nwchemex" - allow_macos_failure: "true" test_pip_build: uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master - with: - allow_macos_failure: "true" diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml index 7a20d9a..ae9c1ad 100644 --- a/.github/workflows/pull_request.yaml +++ b/.github/workflows/pull_request.yaml @@ -29,10 +29,6 @@ jobs: with: doc_target: "scf_cxx_api" - # allow_macos_failure: SCF has a known, tracked, macOS-only segfault (see - # scf-macos-pybind11-segfault.md). macOS still runs and reports its real - # result -- visible signal for the investigation -- but doesn't block this - # workflow or PR merge readiness. Drop once the segfault is fixed. test_cmake_build: uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master with: @@ -40,9 +36,6 @@ jobs: cmake_opts: "-DINTEGRATION_TESTING=ON" python_version: "3.12" extra_pip_packages: "nwchemex" - allow_macos_failure: "true" test_pip_build: uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master - with: - allow_macos_failure: "true" From 920a332e638835eb158bc3390e9b290c0601a3d0 Mon Sep 17 00:00:00 2001 From: "Ryan M. Richard" Date: Tue, 11 Aug 2026 15:10:41 -0500 Subject: [PATCH 2/3] Restore allow_macos_failure for test_pip_build only (separate bug) 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). --- .github/workflows/nightly.yaml | 3 +++ .github/workflows/pull_request.yaml | 12 ++++++++++++ 2 files changed, 15 insertions(+) diff --git a/.github/workflows/nightly.yaml b/.github/workflows/nightly.yaml index 769bc1e..15c8a9c 100644 --- a/.github/workflows/nightly.yaml +++ b/.github/workflows/nightly.yaml @@ -32,5 +32,8 @@ jobs: python_version: "3.12" extra_pip_packages: "nwchemex" + # allow_macos_failure: see pull_request.yaml's comment on the same input. test_pip_build: uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master + with: + allow_macos_failure: "true" diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml index ae9c1ad..d8885ea 100644 --- a/.github/workflows/pull_request.yaml +++ b/.github/workflows/pull_request.yaml @@ -37,5 +37,17 @@ jobs: python_version: "3.12" extra_pip_packages: "nwchemex" + # allow_macos_failure: test_pip_build's macOS gcc-14 leg has a separate, + # pre-existing, unrelated failure -- meson can't detect Homebrew gcc-14's + # linker on macOS ("Unable to detect linker for compiler `gcc-14 + # -Wl,--version`": Homebrew's GCC uses Apple's native ld64 under the hood, + # not GNU ld, and meson's linker probe assumes GNU-compatible --version + # support for any gcc-family compiler) when building numpy from source + # (no cp314-compatible prebuilt wheel; see scf-macos-pybind11-segfault.md's + # original failure table -- this leg failed deterministically even before + # that investigation). Not the pybind11 segfault, not fixed by + # NWChemEx/.github#189. Drop once this is separately investigated/fixed. test_pip_build: uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master + with: + allow_macos_failure: "true" From 55d45d55eac3c2b412f36134d57ddb035e0e348d Mon Sep 17 00:00:00 2001 From: "Ryan M. Richard" Date: Wed, 12 Aug 2026 11:18:31 -0500 Subject: [PATCH 3/3] Scope the build-time numpy<2 cap to Linux; unblocks macOS pip_build 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 --- pyproject.toml | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/pyproject.toml b/pyproject.toml index a218a9d..6235234 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -19,13 +19,22 @@ requires = [ # gau2grid (fetched transitively via GauXC) invokes a Python codegen # script at CMake configure/build time that imports numpy -- needed in # the isolated build env even though scikit-build-core's build-system - # deps are otherwise C++-only. Capped below 2: newer numpy releases only - # ship manylinux2014 wheels for a GCC >= 10.3 build, and manylinux2014's - # own GCC 10.2.1 can't build numpy from source either, so an unpinned - # requirement falls back to a source build that fails outright. This - # cap only affects the isolated build env, not the runtime numpy version - # a user ends up with (see requirements.txt for that). - "numpy<2", + # deps are otherwise C++-only. Capped below 2 on Linux only: newer numpy + # releases only ship manylinux2014 wheels for a GCC >= 10.3 build, and + # manylinux2014's own GCC 10.2.1 can't build numpy from source either, so + # an unpinned requirement falls back to a source build that fails + # outright there. This cap only affects the isolated build env, not the + # runtime numpy version a user ends up with (see requirements.txt for + # that). macOS has no such manylinux/GCC-ABI constraint -- its wheel tags + # are keyed on the deployment target, not the build GCC -- so leaving it + # unpinned there lets pip resolve a real numpy>=2 wheel for whatever + # Python is active (e.g. cp314), instead of falling back to a numpy<2 + # source build that has no cp314 wheel and fails distinctly: Homebrew's + # gcc-14 has no bundled linker, so it shells out to Apple's system ld, + # and meson's linker-detection probe (`gcc-14 -Wl,--version`) fails + # against it ("ld: unknown options: --version") on current macOS/Xcode. + "numpy<2 ; sys_platform == 'linux'", + "numpy ; sys_platform != 'linux'", ] build-backend = "scikit_build_core.build"