macOS: no ILP64 route, because BLAS++ implements only Apple's legacy Accelerate interface

[mmelnich]

Summary

macOS is the one platform where RandBLAS cannot be built against a 64-bit-integer BLAS, and the reason is upstream rather than anything in this repository. The installer currently refuses --blas-int=ilp64 with Accelerate for that reason. This issue tracks lifting the restriction when BLAS++ gains support.

Why it is blocked

Apple has shipped an ILP64 BLAS/LAPACK interface since macOS 13.3, selected by compiling with -DACCELERATE_NEW_LAPACK -DACCELERATE_LAPACK_ILP64. macOS 13.3 actually ships three interfaces: the legacy LP64 (LAPACK 3.2.1, from 2009), a new LP64 (LAPACK 3.9.1), and a new ILP64.

BLAS++ implements only the legacy one. cmake/BLASFinder.cmake emits nothing but:

list( APPEND blas_libs_list "-framework Accelerate" )

and there is no reference to ACCELERATE_NEW_LAPACK or ACCELERATE_LAPACK_ILP64 anywhere in the tree. Adoption of the new interface is tracked upstream as icl-utk-edu/lapackpp#43, still open.

Why it matters here

RandBLAS's own API is int64_t regardless of the BLAS underneath, so most users are unaffected. It matters in two places:

• Sparse work with nnz > 2^31, and the MKL sparse path, which requires MKL_INT to match RandBLAS's int64_t sparse indices.
• Consistency with RandLAPACK. Both projects can default to ILP64 on Linux and Windows. macOS is the only platform where they are forced apart, and only because of this gap.

Note this also means macOS gets the 2009-vintage LAPACK 3.2.1 semantics by default, which is a separate correctness consideration worth its own look.

Done when

• BLAS++ supports Apple's new Accelerate interface (upstream lapackpp#43 or equivalent)
• the BLAS++ pin advances past it
• install/install.sh stops refusing --blas-int=ilp64 for --blas=accelerate
• a macOS CI lane covers Accelerate ILP64
• INSTALL.md's tested-configuration table records the width for macOS

Meanwhile

install/install.sh refuses the combination at argument parsing with a message citing the upstream issue, rather than letting it fail obscurely inside BLAS++.

[mmelnich]

Adding the trigger and one item the original checklist missed.

Trigger. This resolves itself when Mark's new-Accelerate work merges into BLAS++/LAPACK++ — there is nothing for us to write, only to adopt. Upstream tracking is icl-utk-edu/lapackpp#43.

Missing item: re-evaluate the macOS default. The original checklist covers lifting the ILP64 refusal, but Apple's new interface carries a second fix that matters more, and to a different project.

RandLAPACK's installer deliberately defaults macOS to Homebrew OpenBLAS rather than Accelerate, because Apple's legacy Accelerate has a broken divide-and-conquer gesdd and RandLAPACK calls gesdd in five library files (rl_rsvd.hh, rl_abrik.hh, rl_revd2.hh, rl_preconditioners.hh, rl_util.hh). That is also why RandLAPACK #157 quarantines TestQB.Polynomial_Decay_general1. So the new interface unblocks two things at once: ILP64 here, and Accelerate becoming a correct default over there.

Revised checklist:

• BLAS++ supports Apple's new Accelerate interface (ACCELERATE_NEW_LAPACK / ACCELERATE_LAPACK_ILP64)
• the BLAS++ pin advances past it
• install/install.sh stops refusing --blas-int=ilp64 for --blas=accelerate
• a macOS CI lane covers Accelerate ILP64
• INSTALL.md's tested-configuration table records the width for macOS
• RandLAPACK side: re-evaluate its macOS default, and revisit the WIP: remove hard dependence on BLAS++ #157 quarantine (tracked in RandLAPACK FindRandom123.cmake leaks install() rules into downstream projects #159)

Cross-referenced from a RandLAPACK issue so neither side is the only place this is written down.