macOS: MEX fails to load — MATLAB's bundled libomp shadows the one BLAS++ was built against #6

Symptom

On macOS, the MEX files build cleanly and then fail to load inside MATLAB:

Invalid MEX-file '.../matlab/+randlapack/private/bqrrp_mex.mexmaca64':
dlopen(..., 0x0006): Symbol not found: ___kmpc_dispatch_deinit
  Referenced from: .../install/blaspp-openblas-cpu-install/lib/libblaspp.2.0.0.dylib
  Expected in:     /Users/runner/hostedtoolcache/MATLAB/2026.1.999/arm64/MATLAB.app/bin/maca64/libomp.dylib

Cause

MATLAB ships its own libomp.dylib under MATLAB.app/bin/maca64/. Because the MEX runs inside MATLAB's process, that copy is already loaded and wins the symbol lookup over the Homebrew libomp that BLAS++ was actually built against — and it does not export ___kmpc_dispatch_deinit.

This is the mirror image of the Linux constraint already documented in the README: there, MATLAB's runtime MKL must match BLAS++'s integer width; here, MATLAB's runtime libomp must satisfy BLAS++'s OpenMP symbols. Same underlying fact in both cases — inside MATLAB's process, MATLAB's bundled runtime libraries win.

It is also pre-existing: macOS MATLAB has never been green in this repo. Two OpenMP fixes in #3 moved it from a configure failure (Could NOT find OpenMP_CXX) to a build failure (missing omp.h) to this load failure, which is where the real problem was all along.

Fix options

1. Build the macOS stack without OpenMP (preferred). BLAS++ already exposes -Duse_openmp=OFF, and BLAS++ is a thin wrapper over the vendor BLAS — the parallelism lost is negligible next to OpenBLAS's own threading. This needs a --no-openmp option in RandLAPACK's installer, which currently sets MACOS_OPENMP_FLAGS unconditionally (install.sh:310-326), so it is a change in RandLAPACK rather than here.

2. Force the MEX to resolve its own libomp. Fragile: MATLAB's copy is already resident under the same install name, and DYLD_INSERT_LIBRARIES is stripped under SIP for protected binaries.

3. Document macOS + MATLAB as unsupported and point macOS users at the Python bindings, which are unaffected (no MATLAB process, no bundled libomp).

Option 1 is the real fix. Option 3 is what the README says in the meantime.

Current state

• matlab (macos-latest) is continue-on-error with the reason recorded next to the flag.
• matlab (ubuntu-latest), python, and bootstrap all block normally and are green.
• The README's troubleshooting section documents the symptom and the workaround.

Reverting the continue-on-error is the acceptance test for whichever fix lands.