topic Shaijuan in Intel® oneAPI Math Kernel Library

CMAKE and FindMKL or FindLAPACK (Intel® Parallel Studio XE 2016, Windows)

PeterTheRascal — Sat, 15 Oct 2016 21:34:25 GMT

Are there any CMAKE experts on this Forum? If so do you have a version of findMKL or findLAPACK that works for me on modern Intel Fortran/Windows I have not tested them in Linux but suspect they are fine.

Why use CMAKE?

In recent years, I wasted loads of time sorting out “errors” in the ever increasing number of VS properties. So a friend has helped be migrate to CMAKE.

CMAKE is a MAKE package widely used by software professionals. In Windows CMAKE builds a VS solution from a few text files and this has improved my productivity. A typical one of my projects uses:

Fortran (DLL or EXE) calling
Fortran lib (DLL or static)
C++ lib (DLL or static)
Alglib C++

Whole projects were the easity ported to Linux (gfortran and c++) by someone with no experience in either Fortran and CMAKE.

The problem

My problem is including MKL / LAPACK tidily. The “proper” method is to use either FindMKL or findLAPACK. A DIY one would be either hard work and/ or less versatile than a good “maintained” one. But I cannot get any of the versions to work e.g.

findMKL:

https://raw.githubusercontent.com/hanjianwei/cmake-modules/master/FindMKL.cmake

https://github.com/Eyescale/CMake/blob/master/FindMKL.cmake

findLAPACK

github.com/torch/torch7/blob/master/lib/TH/cmake/FindLAPACK.cmake

It could just be an issue of setting parameters (e.g.BL:A_VENDOR) or environmental parameters. I am running from a VS developer cmd prompt and running

"C:\Program Files (x86)\Intel\Composer XE 2015\mkl\bin\MKLVARS.bat" ia32

which sets MKLROOT=C:\Program Files (x86)\Intel\Composer XE 2015\mkl amongst other vars.

To Admin:

PeterTheRascal — Sun, 16 Oct 2016 13:24:25 GMT

To Admin:

Should I have sent this to the MKL forum? If so can you transfer it?

Of shall I just resubmit it to the MKL forum.?

Moved

Steven_L_Intel1 — Sun, 16 Oct 2016 21:08:24 GMT

Moved

Hi Peter,

Shaojuan_Z_Intel — Wed, 19 Oct 2016 17:59:24 GMT

Hi Peter,

We will take a look at the cmake files and will update later. Thanks!

Shaijuan

PeterTheRascal — Tue, 25 Oct 2016 17:35:05 GMT

Shaijuan

Any progress or questions?

Peter

I'm slightly new to all this

Michael_M_17 — Wed, 23 Nov 2016 23:36:23 GMT

I'm slightly new to all this staff (either mkl and cmake), but I have the same problem - trying to "cmake" my project and cannot get the mkl thing working. It is working if all was set manually of course.

would like to have a solution.

Michael

PeterTheRascal — Sat, 24 Dec 2016 20:53:51 GMT

Michael

1. Do you have "good reason" to use CMAKE? I have explained mine above. Otherwise, as Steve L has said elswehere, VS may be fine without it

2. >> It is working if all was set manually of course.

Please clarify

3. In the mean time I am bodging. A snippet from my CMakeLists.txt is:

# MKL extra
SET(Fortran_MKL_COMPILE_FLAGS "/Qmkl:sequential /c")
SET(Fortran_MKL_LINK_FLAGS "mkl_lapack95.lib")
SET( CMAKE_Fortran_FLAGS_DEBUG "${CMAKE_Fortran_FLAGS_DEBUG} ${Fortran_MKL_COMPILE_FLAGS}" )
SET( CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} ${Fortran_MKL_COMPILE_FLAGS}" )
SET( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${Fortran_MKL_LINK_FLAGS} ${Fortran_ALGLIB_LINK_FLAGS}" )

While I could hand load the MKL DLLs, I chose the "safer"/Qmkl options

But I am still desperate for a considered response from Intel. Shaojuan Z, you have been silent for over two months.

I am not a Cmake user, and I

mecej4 — Tue, 27 Dec 2016 10:38:00 GMT

I am not a Cmake user, and I do not work for Intel. It strikes me that "I cannot get any of the versions to work" is too broad a complaint to address. You have not told us what "get it to work" means; you have not shown any error messages that signify "failed", and you have provided no details regarding the OS, compiler version and a test program. So far, no Cmake user has responded in this thread.

I have used MKL extensively with Make, on Windows and Linux, and never ran into a build problem that I could not easily rectify. If you provide specific details, perhaps I can help.

Hi mecej4

PeterTheRascal — Mon, 02 Jan 2017 19:05:37 GMT

Hi mecej4

It seemed unrealistic to run though all the issues I had found with many findLACK.cmake and findMKL.,cmake versions. Rather, I was , I was hoping to find for a CMAKE user who what found a working solution with whatever #.cmake they chose/developed/modified.

But a good start is the findLACK.cmake that is "shipped" with the CMAKE:

Summary
---------
This is a simple test of CMAKE for linking F95 lapack/mkl example gesvd.

MKL_GESVD_issues
This attempts to use the "correct" method via a findLAPACK.cmake. This one is as supplied with the release. Asb shown later, lapack is not found.

Various alternative "DIY" versions can be found on the web. Similarly for findMKL.cmake

MKL_GESVD_fudge (ok)
The compile and link options are "hardwired"

My (latest) tests used
----------------------
cmake-3.7.1-win32-x86.msi on x64 cpu [FROM https://cmake.org/download/]
Windows 10

Microsoft Visual Studio Community 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01586
Installed Version: Community
........
Visual C++ 2015 00322-20000-00000-AA078
Microsoft Visual C++ 2015

To Run CMAKE
-------------
run build_visual_studio_project.bat from explorer or dos prompt
run MKL_GESVD.sln and build Debug and/or Release

mkl_gesvd.exe<gesvd.d (see run.bat)

MKL_GESVD_fudge (ok)
-----------------

run build_visual_studio_project.bat:

C:\Users\xxx\Dropbox\Intelcmake\MKL_GESVD_fudge>"c:\Program Files (x86)\CMake\bin"\cmake -G"Visual Studio 14 2015" .
-- CMAKE_Fortran_FLAGS_RELEASE= /nologo /O2 /libs:static /threads /Qmkl:sequential /c
-- CMAKE_Fortran_FLAGS_DEBUG= /nologo /debug:full /Od /libs:static /threads /dbglibs /Qmkl:sequential /c
-- CMAKE_EXE_LINKER_FLAGS= /machine:X86 mkl_lapack95.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/xxx/Dropbox/Intelcmake/MKL_GESVD_fudge

C:\Users\xxx\Dropbox\Intelcmake\MKL_GESVD_fudge>pause

MKL_GESVD_issues
-------------------
run build_visual_studio_project.bat:

C:\Users\xxx\Dropbox\Intelcmake\MKL_GESVD_issues>"c:\Program Files (x86)\CMake\bin"\cmake -G"Visual Studio 14 2015" .
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- A library with BLAS API not found. Please specify library location.
-- LAPACK requires BLAS
-- A library with LAPACK API not found. Please specify library location.
-- LAPACK_FOUND = FALSE
-- LAPACK_LINKER_FLAGS =
-- LAPACK_LIBRARIES=
-- LAPACK95_LIBRARIES=
-- LAPACK95_FOUND= FALSE
-- BLA_STATIC=
-- BLA_VENDOR= Intel
-- BLA_F95=
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/xxx/Dropbox/Intelcmake/MKL_GESVD_issues

So neither lapack or blas h,ave been found. One clue: when evaluating Nag, it did find some of its lapack files but still "failed".

did I include the zip?

PeterTheRascal — Mon, 02 Jan 2017 21:30:23 GMT

did I include the zip?

I extracted your zip file,

mecej4 — Tue, 03 Jan 2017 23:30:00 GMT

I extracted your zip file, and changed the command in the batch file to cmake -G"Visual Studio 12 2013" to suit my installation (Cmake 3.0.2, VS2013, PS 2016). Running the batch file produced the project files. Running the .SLN file that it generated produced the EXE for the MKL GESVD test program. Running the GESVD program with the data file gesvd.d was successful and produced (seemingly) correct results.

One possible reason for your build failing is that the version of Cmake that you use does not support VS2015 -- my version of Cmake does not; when I ran your batch file, which calls Cmake with -G"Visual Studio 14 2015", Cmake gave the error message "CMake Error: Could not create named generator Visual Studio 14 2015".

This turn of events is quite common with "middlemen" or "fixers" such as Cmake. When you ask them to do things within their repertoire, they please you with how easy they make things for you. When your request strays even a bit outside that repertoire, the result is chaos and disappointment.

Here is the transcript, presumably from findLAPACK.cmake (I changed the Intel Parallel Studio directory name to <IntelDir>).

D:\Intelcmake\MKL_GESVD_fudge> cmake -G"Visual Studio 12 2013"
-- The C compiler identification is MSVC 18.0.31101.0
-- The CXX compiler identification is MSVC 18.0.31101.0
-- Check for working C compiler using: Visual Studio 12 2013
-- Check for working C compiler using: Visual Studio 12 2013 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 12 2013
-- Check for working CXX compiler using: Visual Studio 12 2013 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler using: Visual Studio 12 2013
-- Check for working Fortran compiler using: Visual Studio 12 2013  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Determine Intel Fortran Compiler Implicit Link Path
-- Determine Intel Fortran Compiler Implicit Link Path -- done
-- Checking whether <IntelDir>/compilers_and_libraries_2017/windows/bin/intel64/ifort.exe supports Fortran 90
-- Checking whether <IntelDir>/compilers_and_libraries_2017/windows/bin/intel64/ifort.exe supports Fortran 90 -- yes
-- CMAKE_Fortran_FLAGS_RELEASE=  /nologo /O2   /libs:static /threads /Qmkl:sequential /c
-- CMAKE_Fortran_FLAGS_DEBUG=  /nologo /debug:full /Od   /libs:static /threads /dbglibs /Qmkl:sequential /c
-- CMAKE_EXE_LINKER_FLAGS=   /machine:X86  mkl_lapack95.lib
-- Configuring done
-- Generating done
-- Build files have been written to: D:/Intelcmake/MKL_GESVD_fudge

Thanks mecej4

PeterTheRascal — Wed, 04 Jan 2017 14:03:28 GMT

Thanks mecej4

I can well believe MKL_GESVD_issues problem relates to CMAKE, MKL, or VS versions

But the MKL_GESVD_fudge, that you tested, works fine. Unfortunately it is a "fudge" ("bodge") that bypasses findLAPACK. As such it offers little prospect for a CMAKE future (the merits of which I will not debate now).

Could you possibly see if MKL_GESVD_issues works with your "setup". It may be necessary to change the name of my findLAPACK.cmake to allow yours to find any possible system one. Though, if it does work, I am unclear what I should do next!

Peter

I see, I chose the wrong

mecej4 — Wed, 04 Jan 2017 14:32:59 GMT

I see, I chose the wrong subproject (by the way, including that in your Zip file was a source of distraction, since you knew that it would not give any problems).

I cannot get Cmake to work in "MKL_GESVD_issues". There are too many specifics in your configurations regarding paths, such as C:/Users/Psa/Dropbox/Intelcmake/, and assumptions such as the location of Cmake.exe being in /usr/bin, etc., that do not apply to my Windows system. I get the impression that you have some scripts that have not yet been converted from Linux to Windows. By changing the directories in TargetDirectories.txt, I was able to generate a makefile using Cmake, but that makefile turned out to be defective.

Sorry, I cannot help.

>>There are too many

PeterTheRascal — Wed, 04 Jan 2017 14:51:57 GMT

>>There are too many specifics in your configurations regarding paths, such as C:/Users/Psa/Dropbox/Intelcmake/, and assumptions such as the location of Cmake.exe being in /usr/bin, etc., that do not apply to my Windows system

Which "relevant" file has my hardwired DropBox link?

I agree that findLACK.cmake has not been ported fully from Linux (if at all). That is the problem.

thanks

>>There are too many

PeterTheRascal — Wed, 04 Jan 2017 14:59:14 GMT

Which "relevant" file has my hardwired DropBox link?

I agree that findLACK.cmake has not been ported fully from Linux (if at all). That is the problem.

>> including [ MKL_GESVD_fudge] in your Zip file was a source of distraction, since you knew that it would not give any problems

I am confident that the inclusion offers help, especially for a novice in CMAKE as it shows a functioning MKL link;.

thanks