macOS: default the installer to Accelerate (new interface) with ILP64 - #172
Merged
Conversation
BLAS++ and LAPACK++ merged new-Apple-Accelerate support on 2026-08-27 (icl-utk-edu/blaspp#134, icl-utk-edu/lapackpp#88). The new interface (macOS >= 13.3, LAPACK 3.12 on current SDKs) fixes the legacy gesdd bug, carries the routines BQRRP needs, and ships ILP64 -- so the reasons the macOS default was Homebrew OpenBLAS are gone, and the default build no longer needs any Homebrew BLAS. - Advance the BLAS++/LAPACK++ pins past the merges, in install.sh and the Windows CI provisioner. - install.sh: macOS auto now resolves to accelerate; the gesdd warning and the ilp64-with-Accelerate refusals are removed (the standard prefer-ILP64 width policy applies). A build in which BLAS++ silently fell back to the LEGACY interface is refused right after the BLAS++ build, by checking defines.h for ACCELERATE_NEW_LAPACK; the numerical gesdd conftest remains as the second net. - install-script CI (macOS): the default lane runs without Homebrew OpenBLAS and asserts the summary reports accelerate + ILP64; an explicit --blas=openblas leg keeps that route exercised. - INSTALL.md, INSTALL_SCRIPT.md, docs/CI.md updated to match. Closes #165. Verified on Linux/MKL against the new pins: full installer run end to end (BLAS++ 2d8d4e9 + LAPACK++ b9439cf), then 313/313 tests.
The install-macos lane died at the LAPACK++ configure with no error
text. Cause: macOS ships bash 3.2, where expanding an empty array under
'set -u' is an 'unbound variable' error (fixed in bash 4.4), and the
error went to install.log, which CI never printed. With the old
OpenBLAS default, LAPACKPP_BACKEND_FLAGS was always non-empty on macOS;
accelerate (and mkl) leave it empty, so the default flip exposed the
crash -- it was already reachable with an explicit --blas=accelerate on
any Mac.
Every possibly-empty array expansion now uses the bash-3.2-safe
${arr[@]+"${arr[@]}"} idiom, and the install-script lanes gained an
if-failure step that tails install.log, so this class of failure is
never silent again.
5 tasks
Discovered by this PR's install-macos lane: BLAS++ ILP64 on new
Accelerate works, but LAPACK++ does not compile in that configuration
-- its lapack_int becomes Apple's 'long' while the wrappers' ILP64
no-copy paths assume int64_t ('long long' on Darwin). Filed upstream as
icl-utk-edu/lapackpp#89; the RandLAPACK side is tracked in #173.
Accelerate therefore builds LP64 (what the old OpenBLAS default
produced on macOS as well, so no width regression), and an explicit
--blas-int=ilp64 is refused with a message citing the block. Docs and
the CI assertion updated to match.
Same rename in both repos so the installer layout stays symmetric. The root install.sh wrapper still works and now execs installers/install.sh. References updated in INSTALL.md, INSTALL_SCRIPT.md, INSTALL_WINDOWS.md, docs/CI.md, the install-script workflow, and the Windows guard scripts.
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.
Summary
Follow-up to #155, which retired the legacy-Accelerate accommodations in the library and CI. This PR does the installer half: with new-Accelerate support merged upstream on 2026-08-27 (icl-utk-edu/blaspp#134, icl-utk-edu/lapackpp#88), the reasons macOS defaulted to Homebrew OpenBLAS — the legacy
gesddbug, the missing routines, the missing ILP64 — are gone. The default macOS build now uses Accelerate through Apple's new interface and needs no Homebrew BLAS. (ILP64 turned out to be blocked upstream — see below.)Closes #165 except its ILP64 item, which is split into #173: this PR's own install-macos lane discovered that LAPACK++ does not compile against Accelerate ILP64 (
lapack_intbecomes Apple'slongwhile the wrappers assumeint64_t; filed upstream as icl-utk-edu/lapackpp#89). Accelerate is therefore constrained to LP64 for now — the same width the old OpenBLAS default produced on macOS, so nothing regresses. RandBLAS mirror: BallisticLA/RandBLAS#198 (unaffected: RandBLAS does not need LAPACK++, and its Accelerate ILP64 lanes are green).Changes
installers/install.shand.github/actions/setup-randlapack-deps-windows/setup.ps1advance BLAS++ to2d8d4e9(the fix include paths #134 merge) and LAPACK++ tob9439cf(the Update rl_rbki.hh #88 merge).--blas=autoon macOS resolves toaccelerate(previouslyopenblas).--blas=openblasremains fully supported.defines.hforACCELERATE_NEW_LAPACK— the legacygesddcomputes wrong singular values, so this must be a hard error, not a warning. The numericalgesddconftest stays as the second net. On macOS < 13.3 the error message points at--blas=openblas.--blas-int=ilp64is refused with a message citing New Accelerate ILP64 does not compile: lapack_int (long) vs int64_t (long long) in the ILP64 alias paths icl-utk-edu/lapackpp#89 / macOS: Accelerate ILP64 blocked on a LAPACK++ compile bug (icl-utk-edu/lapackpp#89) #173 (previously the refusal cited the long-gone interface gap).set -uis an "unbound variable" error; with the old OpenBLAS default the affected arrays were never empty on macOS, so the default flip exposed it (it was already reachable with an explicit--blas=accelerateor--blas=mklon any Mac). All possibly-empty array expansions now use the bash-3.2-safe guard, and the install-script lanes printinstall.logon failure so errors of this class are never silent again.brew install openblasanymore, and asserts the summary reportsaccelerate, LP64; a new explicit--blas=openblasleg (with its own project dir and test-suite run) keeps that route exercised.install/folder is nowinstallers/. The rootinstall.shwrapper keeps working (bash install.shunchanged for users) and now execsinstallers/install.sh; references updated in INSTALL.md, INSTALL_SCRIPT.md, INSTALL_WINDOWS.md, docs/CI.md, the install-script workflow, and the Windows guard scripts.