BLAS++ cannot discover an ILP64 OpenBLAS, so --blas=openblas is LP64-only

[mmelnich]

Summary

An ILP64 OpenBLAS exists and is packaged by the major distributions, but BLAS++ never looks for it — so --blas=openblas --blas-int=ilp64 cannot work, and the installer falls back to LP64 with a warning. This is a discovery gap upstream, not a missing library, and it is worth fixing there rather than only working around here.

The gap

cmake/BLASFinder.cmake:384 offers exactly one candidate for the OpenBLAS backend:

if (test_openblas)
    list( APPEND blas_name_list "OpenBLAS" )
    list( APPEND blas_libs_list "-lopenblas" )
endif()

blas_int filters which library names are tried. With one name there is nothing to filter, so requesting int64 changes nothing — and because BLAS++ then probes int32 before int64, a plain LP64 OpenBLAS passes and is accepted. BLAS++'s own comment concedes that an int32 library "passes (erroneously) with blas_int=int64".

What distributions actually ship

Two layouts, and a complete fix has to handle both:

Variant	Library	Fortran symbols	Ships as
unsuffixed ILP64	libopenblas64.so	dgemm_ (64-bit ints)	Debian/Ubuntu libopenblas64-dev, Fedora openblas64
suffixed ILP64	libopenblas64_.so	dgemm_64_	Fedora openblas64_, and OpenBLAS's own recommended INTERFACE64=1 SYMBOLSUFFIX=64_ build

The suffixed variant needs a symbol suffix in the mangling search, which BLAS++ cannot currently express: fortran_mangling_list (BLASFinder.cmake:91-104) offers only ADD_, LOWER and UPPER, and BLAS_FORTRAN_NAME (include/blas/mangling.h:17-23) expands to lower##_, lower or UPPER with no suffix hook.

One detail not to trip over: for Fortran symbols the suffixed variants agree on dgemm_64_, but CBLAS symbols do not — Netlib and MKL use cblas_dgemm_64 while OpenBLAS uses cblas_dgemm64_. BLAS++ needs CBLAS only for its tester, so that can be scoped out, but it should be said rather than discovered.

LAPACK++ needs the parallel change in include/lapack/mangling.h:14-26, and usefully LAPACK_GLOBAL already keys off BLAS++'s defines (defined(BLAS_FORTRAN_UPPER) || defined(LAPACK_FORTRAN_UPPER) and so on), so a consistently named suffix define propagates with roughly a one-line addition and the two libraries cannot disagree about the convention.

Current workaround

Name the library explicitly, which bypasses discovery:

bash install.sh --blas=custom --blas-int=ilp64 \
  --blas-libraries=/usr/lib/x86_64-linux-gnu/libopenblas64.so

Done when

• upstream PRs to BLAS++ and LAPACK++ land (one per repository, each covering both layouts)
• the pins advance past them
• --blas=openblas --blas-int=ilp64 works directly
• the LP64-fallback warning text and the --blas=custom instruction in the install docs are simplified accordingly