LLVM is buildable as a Windows DLL

LLVM Project
1

Building LLVM as a Windows DLL

Following-up on this discussion, the LLVM public interface is now sufficiently annotated to build Clang, LLDB, tools, tests, and examples against an LLVM DLL on Windows. There are a few caveats noted below.

How-to

To build LLVM as a DLL on Windows, include the following CMake options.

LLVM_ENABLE_PROJECTS="llvm;clang;clang-tools-extra;lldb;lld"
LLVM_BUILD_LLVM_DYLIB=ON
LLVM_BUILD_LLVM_DYLIB_VIS=ON
LLVM_LINK_LLVM_DYLIB=ON
CLANG_LINK_CLANG_DYLIB=OFF
CMAKE_BUILD_TYPE=Release

The project can also be built with clang-cl instead of MSVC cl.

CMAKE_C_COMPILER=clang-cl
CMAKE_CXX_COMPILER=clang-cl

The same LLVM_BUILD_LLVM_DYLIB, LLVM_BUILD_LLVM_DYLIB_VIS, and LLVM_LINK_LLVM_DYLIB CMake options can be set when building for Linux with Clang or GCC to produce an LLVM shared library that exports a minimal set of symbols, similar to the Windows DLL.

Limitations

  • The tests do not all pass, primarily due to the LLVM DLL is not being in the path.

  • Until this CI work is complete, annotations on new symbols will likely be missed. In the meantime, documentation for manually adding annotations is here.

  • When the polly project is included, there are issues resolving the getPollyPluginInfo symbol. This issue is tracked here.

  • When the mlir project is included, some executables do not link successfully against the Windows DLL due to duplicate symbol errors. This issue is tracked here.

16 Likes
2

cc @compnerd @vvassilev

3

Wow, this is amazing. Great work!

2 Likes
4

Does this also address the issue of not being able to build the LLVM DLL on MinGW with gcc due to too many exported symbols?

5

Amazing, congratulations on this huge accomplishment!

1 Like
6

If enabled, then this should also address the issue with too many exported symbols, yes.

I haven’t tried this out in mingw environments yet (as things currently work just fine on mingw with clang), but will try it out eventually. There may be some need for tweaks in some places as there are some subtle differences between MSVC style and mingw style for more complex C++ constructs though.

7

Congrats, this is fantastic!

2 Likes
8

Is this windows-only or is it possible to enable this on linux to limit the amount of exported symbols as well?

9

Yes, the same CMake options can be set when building for Linux with Clang or GCC to produce an LLVM shared library that exports a minimal set of symbols.

2 Likes
10

I wanted to give this a try on Linux today… one problem I ran into (apart from missing LLVM_ABI on newly added code) is that we are missing LLVM_ABI on any code guarded by ifndef NDEBUG. This includes many dump() methods.

11

Yeah, this is something that a pre-merge check should hopefully help catch. Enabling a full build in DLL form would be ideal, but we can statically catch a large number of the issues.

That would be a +Asserts build right? That is odd - I thought that it was something that we had tried. But we might’ve missed that.

It really is unfortunate that dump needs to be marked as part of the ABI. Perhaps we should merge the annotation into the LLVM_DUMP_METHOD?

12

I expect that we’ll want to do both. We want to enable the dylib build by default anyway for other reasons, and that would certainly help in making sure that all ABI annotations required to build LLVM are present. This doesn’t really replace ids though, because a DLL build will not catch any symbols that happen to be only used within the DLL, but are intended to also be usable outside if (even if nothing in LLVM itself currently does so).

Yes, this is the -DLLVM_ENABLE_ASSERTIONS=ON build.

The thought crossed my mind, but the issue here is that LLVM_DUMP_METHOD is not used only by LLVM, but also e.g. clang and mlir. So we’d need separate DUMP_METHOD macros for each subproject. It probably makes more sense to just add the LLVM_ABI/CLANG_ABI separately.