Building on Windows with msvc

[Boris Usievich]

Windows is supposed to be a supported platform for MAGMA. However building it on Windows is very complicated … and I have not succeeded yet

1. Tools used: msvs 2022 (Microsoft (R) C/C++ Optimizing Compiler Version 19.34.31937 for x64), Intel OneAPI 2023 (for MKL), cmake 3.25.1
2. Makefile unfortunately uses features that are unsupported in microsoft nmake. So this way is closed.
3. building with cmake from git sources requires to somehow generate a lot of files through codegen.py … which is not supported in CMakeLists.txt and can only be done via the Makefile. I did it by installing Linux in WSL and doing it there. Probably it could be done with cmake, but I not a cmake guru. Now we have full set of sources.
4. First thing you see trying to build with cmake is warning that the compiler does not support C++11. There are 2 problems here. First, microsoft compiler does not have -std=c++11 switch, it should be -std:c++11 for msvc. To make matters worse, the current version of msvc has a minimum supported version of C++14 and the -std:c++11 switch is invalid again. Same goes to -std=c99, msvc has -std:c11 which should be fine. These warnings probably do not affect the build but should be addressed.
5. Finding LAPACK. I have an MKL installation so I set BLA_VENDOR to "Intel10_64lp" and started cmake from a command prompt with Intel environment variables by setvars.bat. LAPACK was found just fine.
6. now project can be generated. VS2022 successfully compiled magma.dll …. and I found that it can’t be used because on windows functions need to be exported from dlls and the magma.dll exported nothing and the corresponding .lib file was not created that prevents its usage even in the magma own tests. Also microsoft compiler has not -fPIC switch that led to hundreds of spurios warnings.

‌

[Boris Usievich]

7. Now trying static library build. seems .lib files are created fine

8. building test. about a dozen of tests failed to compile with errors like this
Error C7660 'max': requires '-openmp:llvm' command line option(s) testing_zgetrf_vbatched D:\magma\current\testing\testing_zgetrf_vbatched.cpp 326

line 326 is #pragma omp parallel for reduction(max:error)

other tests just do not show anything except

D:\magma\build\testing\Debug>testing_caxpy.exe % MAGMA 2.7.0 svn 32-bit magma_int_t, 64-bit pointer. % Compiled with CUDA support for 6.0 % CUDA runtime 12000, driver 12000. OpenMP threads 16.

[Boris Usievich]

Found that tests silently crashed in case when MKL runtime was not found. Why there is no checks?

[Mark Gates]

For modern CMake (>= 3.1), it should do:

set( CMAKE_CXX_STANDARD 11 )
set( CMAKE_CXX_STANDARD_REQUIRED ON )
set( CMAKE_CXX_EXTENSIONS OFF )

set( CMAKE_C_STANDARD 99 )
set( CMAKE_C_STANDARD_REQUIRED ON )
set( CMAKE_C_EXTENSIONS OFF )

instead of setting -std=c++11 and -std=c99.

I would hope — but have no way to test — that CMake would be smart enough to set std:c++14 and std:c11 for MSVC in this case.

[Stan Tomov]

We don’t have the specified Windows setting to test, so we try to “support” Windows based on input from users that have successfully built it. Any input and contribution will be very useful!

Regarding the C++11 issue, I hope the suggestion from Mark works. Please let us know and we can do the update in MAGMA.

For the -fPIC issue, there was pull request recently 0454b96 that addresses the issue for Windows and that we just merged. Please check if that’s the case for you and let us know. Thanks!

[Boris Usievich]

I understand that windows is not the main platform for MAGMA, but unfortunately my application runs on it and now I am trying to take advantage of GPUs are requested by some users. Static library seems working OK, tests are passed. Shared library (dll) currently can’t be used on windows because of the export issue.

Suggestion from Mark works. Warnings gone, compilation is just fine.

[Theodore Chang]

Shared library (dll) currently can’t be used on windows because of the export issue.

Plenty of resources to instruct how to generate a lib from a dll. See for example:

https://github.com/KHeresy/GenLibFromDll

‌

Regarding all the above issues, IMHO, compiler definitions could be set by add_definition, compiler flags need to have a more refined control for different compilers, some auto-conversion is available from CMake but it is not worry-free. fPIC shall be set by set(CMAKE_POSITION_INDEPENDENT_CODE ON). These are more idiomatic ways to lead to cross-platform compatible configuration.

‌

I am trying to compile v2.7.0 with CUDA 12 but since texture support is removed, errors are thrown from some files, e.g., magmablas\gemm_stencil_defs.h.

[Boris Usievich]

I am trying to compile v2.7.0 with CUDA 12 but since texture support is removed, errors are thrown from some files, e.g., magmablas\gemm_stencil_defs.h.

To compile with CUDA 12 you need to get a newer version from git

[Boris Usievich]

Plenty of resources to instruct how to generate a lib from a dll.

The problem is that the procedure can only create .def and .lib for those exports that are already present in .dll. This does not apply to magma.dll. In windows there are two ways to tell the linker to export a symbol from the dll.

1. create a .def file with a list of exported functions and variables. MAGMA doesn’t do this
2. add __declspec(dllexport) to the definitions of the functions and variables to be exported. MAGMA doesn’t do this either

As a result the linker creates a .dll with no exports and no corresponding .lib

There is a CMAKE variable to deal with this problem:set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON). However this approach doesn't succeed in MAGMA case.

1. it exports every function including internal MAGMA machinery. That makes an export list in dll very large and will probably slow down the dll loading.
2. it doesn’t export variables so even the test programs linking can’t find constant variables like MAGMA_Z_INF

‌

[Theodore Chang]

To compile with CUDA 12 you need to get a newer version from git

Thanks, I was not following closely to the development. Tried master and succeeded.

[Theodore Chang]

As a result the linker creates a .dll with no exports and no corresponding .lib

Oh, Okay, that’s sad. It’s sadder that it seems only magma_winthread is labelled by MAGMA_DLLPORT.

[Boris Usievich]

One more problem I encountered. When building with Intel MKL on Windows, find_package( LAPACK ) always uses the dll version of MKL, even if BLA_STATIC is set to ON. This is not a MAGMA problem since this is done by the standard cmake module FindLAPACK. However if somebody, like me, needs to statically link MKL, he has to to manually change the LAPACK_LIBRARIES variable to remove the _dll suffix in the library names.

‌