cannot build magma on windows

[cdel]

Hi,

I am trying to generate magma.lib ,magma_sparse.lib and tester.lib by building magma with Visual Studio 2019 on Windows 10 but I am getting hundreds of link errors. 

I have downloaded magma 2.5.4 and I have followed the instructions in README-Windows, where it says that after building the project in Visual Studio one should find the MAGMA library and testers in  build\lib\Debug\ and build\testing\Debug\ assuming a build folder was created to contain the generated project.

I have generated the project using CMake (v3.19.4), platform x64 using visual studio 16 2019 as a generator. I get the warnings saying that -std=c++11 flag and -std=c++99 flag is not supported by cl.exe, but, the project is still generated.

After the project has been generated, I have tried to build MAGMA.sln on Visual Studio, but I got this kind of link error :

Severity Code Description Project File Line Suppression State

Error LNK1104 cannot open file 'lib\Debug\magma_sparse.lib' testing_cio C:\Users\cdelf\Documents\magma-2.5.4\build\LINK 1

So I don't quite understand how am I suppose to generate lib files which the projects depend upon in order to be built. What am I doing wrong here?

Thanks for your answer

cdel

[junny]

Hi cdel,

Any update on this problem? I have the same setup and errors that you are getting. Building the magma.sln gives me more than 700 errors.

Would it be useless if we make the lib files in ubuntu and use them in visual studio? I am currently thinking of doing just that.

junny

[Christian]

Hi cdel,

From the description of your problem, it seems that you are compiling the tests, (see `testing_cio` in the error) when it gives you the dependency error. I am going by memory, so please excuse any mistake, but I believe that CMake configures the solution to compile everything: library and tests. In Visual Studio a "Solution" is a collection of projects which may or may not depend on each other. If it all works correctly, it should compile the library first and then the tests. Perhaps the CMake file for Windows is missing a dependency between the tests and the library project, so Visual Studio goes merrily ahead and decides to compile the tests first, hence the missing dependency. Try compiling the library project only (right-click on the magma library project, then build, I believe).

Cheers

[Keith Ballard]

Hi All,

As a preface, I am new to magma, but very familiar with scientific computing on linux and windows.  It does seem like there are significant issues building magma on windows. Some issues have been raised in the other forums:

• https://icl.cs.utk.edu/magma/forum/viewtopic.php?t=4119
• https://icl.cs.utk.edu/magma/forum/viewtopic.php?t=4008
• https://icl.cs.utk.edu/magma/forum/viewtopic.php?t=4014

Some underlying include:

• A well-documented issue with using CMake with Visual Studio generator to build the CUDA backend. This issue is due to the fact that CMake uses full paths in the link statement to create the intermediate object with NVCC, resulting in commands longer than the command-line limit.  For the latest version of magma, this is unavoidable with very short paths. A build directory of C:/b is still about 3k characters too long. You can look at magma.vcxproj in a text editor to find the ridiculously long command. This issue can be worked around by using the Ninja generator instead.
  
• Building source with USE_FORTRAN=OFF results in a lapacktest.dll but no lapacktest.lib. The reason for this issue is that no function is marked as exported with dllspec. Consequently, you will get a link error when building tester.dll. I added a dummy source file to provide a dummy exported function, forcing the creation of the lapacktest.lib. However...this is related to a larger problem.
  
• When building magma as a shared library, all of the core functions are not marked as exported, thus creating plenty of unresolved external errors.  Currently, I am testing if static libraries work, since all functions should be included in the library, but I will also test if adding exports to core functions ameliorate the unresolved external externals.

I will keep you updated, but I hope my findings thus far help provide some direction.

Thanks,

Keith Ballard