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.

[rmathar]

On Ubuntu 25.10 (Debian) the same 4 error messages
of not finding openblas/clabs.h cblas.h etc emerge.
After

  apt install libopenblas-dev
  apt install libfftw3-dev
  apt install liblapack-dev
  apt install liblapacke-dev

The directory layout is mixed:

  /usr/include/x86_64-linux-gnu/cblas.h
  /usr/include/lapacke.h

as already said. The current m4/acx_openblas.m4 of sextractor searches
with AC_CHECK_HEADERS first for include/openblas/* where it does find neither cblas.h nor lapacke.h
because these search directories don't have an intermediate "openblas" directory.
Then it searches with AC_CHECK_HEADER for cblas.h and lapacke.h.
If the implementation were

  AC_CHECK_HEADER([cblas.h],,...)
  AC_CHECK_HEADER([lapacke.h],,...)

both header files would be found, but because both are searched with
AC_CHECK_HEADER([cblas.h lapacke.h],..), note the singular (!), they are not found.
I guess the underlying m4 expansion is searching in this case for

  #include "cblas.h lapacke.h"

or something similar garbled up, and that does not exist. So the first patch to
this problem is to unbundle these two searches,
and then ./configure --enable-openblas works without specifying --with-openblas-incdir .

The Ubuntu libraries are

   /usr/lib/x86_64-linux-gnu/libopenblas.so
   /usr/lib/x86_64-linux-gnu/liblapacke.so

and the library liblapacke.so has the symbol:

user@Ubuntu:/usr/lib/x86_64-linux-gnu$ nm -D liblapacke.so | fgrep dpot
00000000000ed390 T LAPACKE_dpotrf
00000000000ed110 T LAPACKE_dpotrf2
00000000000ecf30 T LAPACKE_dpotrf2_work

whereas the library libopenblas.so does not have it:

user@Ubuntu:/usr/lib/x86_64-linux-gnu$ nm -D libopenblas.so | fgrep dpot
00000000008ddb90 T dpotf2_
0000000000b6fa20 T dpotf2_L
0000000000b6f850 T dpotf2_U
00000000004696d0 T dpotrf2_
00000000008dd800 T dpotrf_
0000000000b6ccb0 T dpotrf_L_parallel
0000000000b6c390 T dpotrf_L_single
0000000000b6c9a0 T dpotrf_U_parallel
0000000000b6bdc0 T dpotrf_U_single
0000000000469af0 T dpotri_
0000000000469c70 T dpotrs_

Unfortunately the situation is different for openSUSE, where libopenblas.so has
both of these symbols sets

mathar@openSUSE:/usr/lib64> nm -D liblapacke.so.3 | fgrep dpotrf
0000000001a9a570 T LAPACKE_dpotrf
0000000001a9a7d0 T LAPACKE_dpotrf2
0000000001a9a860 T LAPACKE_dpotrf2_work
0000000001a9a600 T LAPACKE_dpotrf_work
00000000014553d0 T dpotrf2_
000000000014efd0 T dpotrf_
0000000000394680 T dpotrf_L_parallel
0000000000393de0 T dpotrf_L_single
0000000000394360 T dpotrf_U_parallel
0000000000393830 T dpotrf_U_single

and liblapacke.so.3 has them also. Now we cannot just
search in liblapacke.so because the suffix .3 masks the library from
being searched by the standard autotools (unless one introduces a symbolic link).
So the patch probably would involve not searching for LAPACKE_dpotrf
but for dpotrf2_ for compatibility with both openSUSE and Ubuntu.

Both patches combined:

--- acx_openblas.m4.org 2025-06-17 16:08:37.330155874 +0200
+++ acx_openblas.m4     2025-06-17 18:04:12.910722474 +0200
@@ -53,8 +53,12 @@
     [
       [acx_openblas_incdir=""]
       AC_CHECK_HEADER(
-        [cblas.h lapacke.h],,
-        [OPENBLAS_ERROR="OpenBLAS header files not found!"]
+        [cblas.h],,
+        [OPENBLAS_ERROR="OpenBLAS header cblas.h not found!"]
+      )
+      AC_CHECK_HEADER(
+        [lapacke.h],,
+        [OPENBLAS_ERROR="OpenBLAS header lapacke.h not found!"]
       )
     ]
   )
@@ -88,6 +92,7 @@
     acx_openblas_suffix=""
     OPENBLAS_CFLAGS=""
   fi
+
   if test x$1 = x; then
     acx_openblas_libopt=""
   else
@@ -109,7 +114,7 @@
     )
   else
     AC_SEARCH_LIBS(
-      [LAPACKE_dpotrf], ["openblas"$acx_openblas_suffix],,
+      [dpotrf2_], ["openblas"$acx_openblas_suffix],,
       [OPENBLAS_ERROR="OpenBLAS"$acx_openblas_suffix" library file not found!"],
       $acx_openblas_libopt
     )

[rmathar]

The nice thing is that the same problem exists on the cmake side : opencv/opencv#9953 so we are not alone with this.