Cannot build on Debian without libatlas

[olebole]

On Debian, the atlas packages are going to be removed with the next release, which also affects the Astromatic packages (see f.e. Debian#1056688). As alternatives, we have openblas and lapack on their standard (Debian) places:

• /usr/include/x86_64-linux-gnu/cblas.h and /usr/lib/x86_64-linux-gnu/libopenblas.so for openblas,
• /usr/include/lapacke.h and /usr/lib/x86_64-linux-gnu/liblapacke.so for lapacke.

all these files are in the standard include resp. lib paths, and therefore no -I… or -L… flags would be needed. However, the configure step fails stating that

$ ./configure --enable-openblas
[…]
checking for openblas/cblas.h... no
checking for cblas.h lapacke.h... no
checking for openblas/lapacke.h... no
checking for cblas.h lapacke.h... (cached) no
configure: error: OpenBLAS header files not found! Exiting.

and with explicitly searching in /usr/include/x86_64-linux-gnu/

$ ./configure --enable-openblas --with-openblas-incdir=/usr/include/x86_64-linux-gnu
[…]
checking for /usr/include/x86_64-linux-gnu/cblas.h... yes
checking for library containing LAPACKE_dpotrf... no
configure: error: OpenBLAS library file not found! Exiting.

The mentioned function is however in lapacke.h:

$ grep LAPACKE_dpotrf /usr/include/lapacke.h 
lapack_int LAPACKE_dpotrf2( int matrix_layout, char uplo, lapack_int n, double* a,
lapack_int LAPACKE_dpotrf( int matrix_layout, char uplo, lapack_int n, double* a,
lapack_int LAPACKE_dpotrf2_work( int matrix_layout, char uplo, lapack_int n,
lapack_int LAPACKE_dpotrf_work( int matrix_layout, char uplo, lapack_int n,

I think that is a problem with the m4 autoconf macros that they are irritated the different (although standard) directories for cblas.h and lapacke.h. Could they be extended so that they also search in the standard include paths?

[ebertin]

Thanks for the heads up! Time to revisit that old openblas m4 file I guess. The openblas config path still works great on Fedora 40 though. Not sure I understand all the subtleties of the various BLAS avatars on Debian; help from an insider would be much appreciated.

[olebole]

I'd be happy to help here. The "rule of thumb" is that the libraries on Debian can be found on the standard include resp. library directories, without the need of -I or -L flags; so a simple test whether one can "just link" a library would be sufficient.

The library dir is /usr/lib or /usr/lib/<arch> for libraries (with <arch> being the architecture triple, like x86_64-linux-gnu), the include dir is /usr/include or /usr/include/<arch>. The paths with <arch> are preferred for architecture dependent files, but not all packages do this. But, as I wrote: usually, one doesn't need to know the paths, as they are the default ones when compiling/linking, which could be checked first.

If you have more questions, I'd gladly help.

[ningli-amd]

How about creating a new set of rules to detect BLAS and LAPACK separately? While Atlas and OpenBLAS have BLAS/LAPACK in the same library files, other modern implementations may have BLAS and LAPACK in separate packages, such the open-source Blis and Libflame libraries, or AMD's AOCL BLAS/LAPACK. Currently it is fairly hard to reuse the configurations for Atlas/OpenBLAs with the new libraries.