search

DrTimothyAldenDavis / SuiteSparse

The official SuiteSparse library: a suite of sparse matrix algorithms authored or co-authored by Tim Davis, Texas A&M University.
https://people.engr.tamu.edu/davis/suitesparse.html
Other
1.14k stars 258 forks source link

Building static and shared libraries with LLVM Clang on Windows fails #749

Closed mmuetzel closed 6 months ago

mmuetzel commented 6 months ago

In the closed issue #309, @chengts95 noted in the 30th comment:

I got ninja: error: build.ninja:215: multiple rules generate SuiteSparse_config/suitesparseconfig.lib with clang+ninja on windows. May be caused by shared and static library options.

Probable cause is using a version of LLVM Clang with MSVC backend.

@chengts95: Just to make sure that we are on the right track: Does it work if you use clang-cl instead of clang and clang++?

chengts95 commented 6 months ago

I want to point out that on Windows, there are two types of ecosystems: 1. Gnu-like toolchain and libraries from msys2, which won't use the Windows headers and standard libraries; 2. Native Win32 ecosystem with MSVC. The msys2 can have the gnu Clang compiler, but the Clang in LLVM for Windows is a frontend for the Win32 ecosystem (because clang and LLVM are not GNU so they are not bundled with GNU ecosystems), which relies on MSVC and uses native Win32 headers and libraries. Clang-cl is designed to be C++ ABI-compatible with MSVC, so the libraries are still using Win32 rules, which must have a .lib for both dynamic and static targets.

The current CMakefiles and some complex-number-related codes didn't notice that other compilers can use the same libraries from MSVC (Windows SDK). The current CI of SuiteSparse only tests with MSVC for the native Windows ecosystem.

The reason to use clang with MSVC ecosystem: vcpkg mainly uses clang on Windows, and it can have a problem if we mix msys2 and native win32 libraries. Besides, MSVC only supports OpenMP 2.0 while clang on windows supports OpenMP 5.1. So I hope we can have a better solution on Windows.

mmuetzel commented 6 months ago

Besides, MSVC only supports OpenMP 2.0 while clang on windows supports OpenMP 5.1. So I hope we can have a better solution on Windows.

As a work-around, you could use clang-cl for the time being that also supports OpenMP 5.1 but is already correctly handled by the current build rules.

I'm working on a fix to correctly handle clang from MSVC for this issue and will open a PR shortly.

mmuetzel commented 6 months ago

See #752.

chengts95 commented 6 months ago

It will also have a problem to include "complex.h" when using the clang with the GNU command line on Windows. So maybe in that case the 2 issues should be solved together. Besides, we should notice that the ninja generator doesn't work well with clang-cl :ninja issue.

mmuetzel commented 6 months ago

It will also have a problem to include "complex.h"

That is a different issue. See #751

mmuetzel commented 6 months ago

Besides, we should notice that the ninja generator doesn't work well with clang-cl

If you are running into issues with the Ninja generator, using a Visual Studio generator with -TClangCl might be an option.

chengts95 commented 6 months ago

Besides, we should notice that the ninja generator doesn't work well with clang-cl

If you are running into issues with the Ninja generator, using a Visual Studio generator with -TClangCl might be an option.

Yes, but I found my vs doesn't have a ClangCL tool kit option, i think it requires installing Clang inside Visual Studio. I am looking forward to having better treatment for Windows compilers so we can avoid Visual Studio problems and only make it depend on Windows SDK.

mmuetzel commented 6 months ago

This issue is fixed now and covered in CI.