[CMake] problem with FindBLAS.cmake looking for cblas_dgemm

Michael Wild themiwi at gmail.com
Wed Jun 2 08:08:23 EDT 2010


On 16. Jul, 2009, at 11:45 , Vardan Akopian wrote:

> Hello,
> 
> I'm using cmake 2.6.2.
> While trying to use the FindLAPACK module on a Linux system which has
> ATLAS installed I stumbled upon a problem where the BLAS libraries
> would not be found. By digging into FindBLAS.cmake I discovered that
> when checking for the ATLAS libraries, the module tries to make sure
> that the cblas_dgemm function is there and can be compiled within a
> Fortran program. I find this a bit puzzling for a couple of reasons:
> 1) when compiled with GNU or Intel fortran (and I guess with most of
> the other) compilers, the generated symbol would be cblas_dgemm_
> (notice the underscore at the end). However the cblas library which
> comes with ATLAS will have this symbol without the underscore, and
> thus will not link.
> 2) why do we need to make sure cblas_dgemm function works? Isn't the
> "cblas" part kind of an implementation detail? Why not just check for
> dgemm function which is actually part of the BLAS interface?
> 
> Anyway, in my installation, the way FindBLAS.cmake is, it will fail
> finding BLAS (and therefore LAPACK) that's provided by ATLAS. However,
> by simply changing FindBLAS.cmake to look for the "dgemm" function
> instead of "cblas_dgemm" everything works just fine.
> Am I missing something? Wouldn't it be better to look for dgemm
> instead of cblas_dgemm?
> 
> Thanks.
> -Vardan

Just to correct a thing: cblas_dgemm is NOT an implementation detail, it is part of CBLAS which is the official C-interface to BLAS.

But like you I'm pretty unhappy with FindBLAS (and FindLAPACK). Part of the problem is probably the fact that BLAS and LAPACK are notoriously difficult to compile and link against. Every implementation is fundamentally different from the other, and even vary in between version so much, you probably couldn't tell their from the same vendor (e.g. Intel MKL). Just take a look at the Intel linking advisor to get an idea of how complex it is to get things right (http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor). And mind you, that's only one product...


I think it would be best to split these modules into sub-parts:

FindMKL (Intel)
FindACML (AMD)
FindAccelerate (Apple)
FindATLAS (ATLAS)
FindPHiPAC (fast dgemm)
FindLibSci (Cray)
FindCXML (DEC/Compaq/HP)
FindMLIB (HP)
FindESSL (IBM)
FindPDLIB (NEC)
FindSCSL (SGI)
FindSunPerf (Sun)
FindNASVecLib (NASoftware)
FindGenericBLAS (e.g. netlib)
FindGenericLAPACK (e.g. netlib)
...

And then FindBLAS and FindLAPACK use these to find viable candidates. Possibly they also add an option to the cache allowing one to select which of the available implementations to use. One could also think of the possibility that the programmer might exclude certain BLAS/LAPACK implementations (e.g. ATLAS because it is not complete). This would break the large problem into smaller, more manageable parts.

Michael


More information about the CMake mailing list