Add blas_symbol_suffix CMake option for symbol-suffixed BLAS libraries

[rileyjmurray]

Lets BLAS++ link against BLAS libraries whose Fortran symbols carry a suffix, e.g. OpenBLAS built with INTERFACE64=1 SYMBOLSUFFIX=64_ exports dgemm_64_ instead of dgemm_. Motivation is downstream consumers (e.g., conda-forge blaspp-feedstock) that want a clean ILP64 build against libopenblas64_ in the same prefix as the LP64 build.

Adds a new CMake cache var blas_symbol_suffix (empty by default, strict no-op) that propagates as -DBLAS_FORTRAN_SUFFIX=<value> into:

• include/blas/mangling.h (consumer-visible name mangling)
• config/config.h (compile/link probes in BLASFinder)
• installed defines.h, via blaspp_defs_, so downstream consumers see the same name mangling.

When the suffix is set, the OpenBLAS search probe links -lopenblas${blas_symbol_suffix} to match upstream library naming convention (libopenblas64_).

[rileyjmurray]

@tdehoff and/or @mgates3 please review when able :)

[rileyjmurray]

Question: Does this need to apply to CBLAS/LAPACKE wrappers too? OpenBLAS suffixes CBLAS symbols as cblas_dgemm64_. BLAS++ itself does not link CBLAS, but LAPACK++ does. If a parallel patch is needed in LAPACK++ for lapack_symbol_suffix, I can open one.

EDIT: above is from a robot (along with all commits in this PR).

[mgates3]

LAPACK++ doesn't link with CBLAS.

Perhaps BLAS++ and LAPACK++ use CBLAS and LAPACKE for their testers, but the libraries themselves both directly wrap the Fortran interface, not the CBLAS or LAPACKE interface. (Granted, some libraries are reversed: the Fortran interface is a wrapper around the CBLAS interface.)

[rileyjmurray]

Gotcha, RE: LAPACK++ not linking with CBLAS.

Another question for you, @mgates3.

I just landed a PR getting an updated BLAS++ in conda-forge. That PR's implementation set three different internal CMake cache variables across BLASFinder, BLASConfig, and CBLASConfig (blas_libraries_cached / blas_found_cached, blas_config_cache, cblas_config_cache) to facilitate cross-compilation. The naming is inconsistent (_cached vs _cache) and they're all INTERNAL cache variables, so the workaround is poking at the implementation rather than a documented contract.

EDIT: crossing out questions based on Mark's response at conda-forge/blaspp-feedstock#10 (comment). In my next blaspp-feedstock PR I'll revert the changes that related on undocumented CMake config variables above.

I'd like to clean this up, but I don't want to overload this PR. I've given three options below. Can you like me know what you prefer? Either of the latter two options give us a chance to normalize the _cached / _cache naming while we're at it.

Option 1: defer. Land this PR as-is for the symbol-suffix work, and I'll open a separate issue + PR for the cross-compile detection cleanup afterwards.

Option 2: treat BLAS_LIBRARIES + blas_int as a trust contract. When the consumer has set both, short-circuit the detection loop in BLASFinder and skip the vendor-version probes in BLASConfig / CBLASConfig. No new public option; the contract is "if you've told us what BLAS is and how wide its integers are, we believe you." Today, even an explicit BLAS_LIBRARIES still triggers the full try_compile × mangling × int-size loop, since the gate at BLASFinder.cmake:25 is STREQUAL blas_libraries_cached rather than if (BLAS_LIBRARIES). Trade-off: changes the meaning of BLAS_LIBRARIES from "constrain the candidate list" to "skip detection entirely," which is a behavior change for anyone passing it on a native build.

Option 3: add a first-class skip flag. Add a single public CMake option, e.g. -Dblaspp_skip_blas_detection=ON, that gates the search loop in BLASFinder and the version probes in BLASConfig / CBLASConfig, and requires the consumer to pass BLAS_LIBRARIES, blas_int, and any BLAS_HAVE_* defines they want set. Could default to ON when CMAKE_CROSSCOMPILING is true and the required inputs are present. Trade-off: one new public option to document and maintain, but BLAS_LIBRARIES keeps its current meaning.

Finally, can you approve the CI workflow? I imagine "passing CI" is a prerequisite to merge this PR.

[mgates3]

I would have to review the exact behavior, but I think setting BLAS_LIBRARIES and blas_int=int64 should constrain it so it tests only 64-bit versions. It will still test all the mangling options, unless that is also constrained. In other words, if you provide enough constraints, it ideally should try_compile only 1 option.

[rileyjmurray]

Thanks for the feedback Mark. I've pushed updates:

• Added -lopenblas64 to the BLAS++ search (CMake + Make). The ILP64 OpenBLAS that Debian/Ubuntu ship as libopenblas64 (plain dgemm_ symbols) now auto-detects with no BLAS_LIBRARIES and no BLA_VENDOR.
• Extended blas_symbol_suffix to the Make/configure.py build. It was CMake-only before; config/lapack.py now probes -lopenblas${suffix} and writes BLAS_FORTRAN_SUFFIX into defines.h, so calls mangle to dgemm_64_. Still opt-in (empty default = no change), so MKL/ESSL etc. are unaffected.

Verified on a stock ubuntu-latest runner — built libblaspp four ways:

build	BLAS	result
CMake	apt libopenblas64-dev, auto-detect	finds -lopenblas64, builds
Make	apt libopenblas64-dev, auto-detect	finds -lopenblas64, builds
CMake	conda libopenblas-ilp64, blas_symbol_suffix=64_	finds -lopenblas64_, builds
Make	conda libopenblas-ilp64, blas_symbol_suffix=64_	finds -lopenblas64_, builds

Logs attached. LMK if other changes are needed!

04-make-conda-suffix.log
03-make-apt-auto.log
02-cmake-conda-suffix.log
01-cmake-apt-auto.log