[CMake] FindLAPACK in git head

Maik Beckmann beckmann.maik at googlemail.com
Tue Oct 18 06:38:06 EDT 2011


libmkl_lapack has been removed from 10.2. which is the version that
ships with intel 11.1 .
 - http://software.intel.com/en-us/articles/dummy-libraries-have-been-removed/

BLAS and LAPACK are part of libmkl_core, which was already found by
FindBLAS and hence BLAS_LIBRARIES already contains everything needed.
And yes, it is a mess.

FindBLAS broke for intel 12, since it's MKL version (10.3) removed
libguide, which has been replaced by libiomp5.

I'm working on a FindMKL.cmake, which is meant to be used by FindBLAS
and FindLAPACK.  As alway I'm short on time, so it's not finished yet.
 There came another issue up with forced to skip my efforts and
locally (in our trunk) make changes to FindBLAS and FindLAPACK to
support intel 12 for x86_32 and x86_64 Windows, static linking.


What has been done so far:
- After having spend a few days reading all MKL 10.0 to 10.3 docs and
ssh'ing into the RWTH Aachen Linux cluster, where all these versions
are installed, I feel comfortable about the 10.x linking process.
- Before that, I toyed with rewriting FindBLAS (and FindLAPACK) first,
which made me realize that MKL is just causing too much noise in there
and has to be put in its own module.  I've send the FindBLAS rewrite
draft and my notes on it to Alexey Ozeritsky, the current maintainer
of these modules.  It foremost allows to overrule the sets of
libraries for BLAS but only reports BLAS_FOUND if these libraries
actually work (no missing references).

TODO:
 - I've gathered all I could find about the pre 10.x linking process,
but I don't have a machine to test right now.   We have an old PC that
has VS 2002, ifort 9 and MKL 7.2.1 installed gathering dust in a
corner, but it has to be re-registered by our IT have it access the
net and hence the license server.   I know it's silly, but well.  If
anyone has an ssh access to spare with old intel and MKL versions
installed, send me a mail.
- Within FindMKL I need to know exactly which MKL version I'm dealing
with.  intel doesn't hold back with breaking changes and the best way
to deal with it is by version numbers, including the minor numbers.
- My guts tell me it's a good idea to figure the intel compiler
version number as well, for a good measure and for possibly leveraging
the new -mkl/Qmkl compiler switches .  Ofc there is no portable
compiler switch to figure this.  I have to compile and run an
executable from a code snippet that outputs the version number given
by an preprocessor symbol.


I'm sorry Tim that this isn't ready for prime time yet.  Knowing that
there is demand beyond our group I will allocate some time for it.  I
will ready a draft for 10.x and add pre 10.x support later,  this way
at least you can get going.

Best,
Maik Beckmann


More information about the CMake mailing list