Don't build LLVM with the -DLLVM_BUILD_SHARED_LIBS CMAKE option

[Keithcat1]

Currently LLVM is built dynamically, with each LLVM component being its own DLL.
However, this for some reason causes LLD, the LLVM's linker, to sometimes hang and never complete. This might also happen when invoking Clang, but it seems much rarer (it happened to me once).
Also, LLVM's CMAKE documentation states that:
Note
BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.
The LLVM_BUILD_LLVM_DYLIB option is unavailable on Windows however.
Statically linking LLVM executables might also increase performance somewhat.

[brechtsanders]

I have built LLVM statically in the release I just published (https://github.com/brechtsanders/winlibs_mingw/releases/tag/11.1.0-12.0.0-9.0.0-r1).
Does that resolve the issues you had?

[Keithcat1]

Looks like it. Thanks.

[chawyehsu]

The static LLVM build bumps the release's size crazily. I would suggest providing a variant for users who care about the size to download a dynamic linking version of winlibs mingw llvm, though I think the dynamic linking version should be the default one.

BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.

One should know this. On Windows, shared libraries may be used when building with MinGW, including mingw-w64, but not when building with the Microsoft toolchain.

The LLVM_BUILD_LLVM_DYLIB option is unavailable on Windows however.

https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt#L611-L623

This is not true. Actually, LLVM_BUILD_LLVM_DYLIB is only unavailable for MSVC on Windows. For MinGW, it's optional, and it has been used by other builds such as MSYS2's llvm.

However, this for some reason causes LLD, the LLVM's linker, to sometimes hang and never complete. This might also happen when invoking Clang, but it seems much rarer (it happened to me once).

This is not the reason to choose to use static build I think. If unexpected behaviors occur when using the dynamic build, why not try to report an issue to LLVM for improvement.

[brechtsanders]

I have switched LLVM from shared to static builds after issues reported #56.
Another reason the file got a lot bigger is the addition of AVR target support (see #60), which probably wasn't a good idea, and should probably be a separate archive.

Main focus of winlibs.com is on GCC. Pinpointing issues in LLVM stability is not taken in scope.

[chawyehsu]

Another reason the file got a lot bigger is the addition of AVR target support

The size does increase a bit because of the AVR files, but static LLVM makes the size changing from a MB level to a GB level.

Main focus of winlibs.com is on GCC.

I agree with this. But the point I said is don't switch to static build, of which the goal is just for a rare, happened only once, issue that the author is encountering when we can use LLVM_BUILD_LLVM_DYLIB=ON to build a dylib version of LLVM for MinGW (not msvc).

Anyway, the decision is yours. I've deprecated this huge thing from my workflow.

[Keithcat1]

I have encountered the problem with LLVM multiple times, not only once. The problem is that every time you run ld.lld, the LLVM linker, there is a chance it will never complete.
The LLVM_BUILD_LLVM_DYLIB is not supported on Windows see
Also there are archives both and without LLVM on the Winlibs website.

@brechtsanders
You might be able to get smaller binaries by building Clang with Clang. I don't know if that's true, but LLVM Mingw's clang is only 85 MB while here it is 115 MB at least.

Also see which might have a fix.