Supporting LLVM_BUILD_LLVM_DYLIB on Windows

Hi,

I have been working on this lately and I wanted to provide and update with some of the challenges that I’m facing.

My goal is to explicitly export symbols for all of libLLVM.so on both Windows and Linux, so I’ve been trying to find a way to achieve this with a single macro that will expand to __attribute__((__visibility__("default"))) on linux and __declspec(dllexport) on Windows. My first approach was to add this macro to class definitions:

class LLVM_ABI foo {
};

This worked on linux, and I was able to do a complete build of llvm, clang, lld, lldb, and mlir with these attributes. However, went I went to test this on Windows, the build failed due to C2280: attempting to reference a deleted function. This seems to be a problem with msvc generating and exporting a copy constructor for classes with containers of std:unique_ptrs. I was able to fix a few of these errors with some suggestions from online sources but there were more that I was unable to fix.

Because of this issue, I decided to change my approach and annotate the member functions instead of the classes themselves. It turns out, though, that this does not work on Linux, because neither clang nor gcc export the vtable unless the visibility attribute is attached to the class. msvc will export the vtable if any member functions have dllexport.

My next attempt after this was to try and annotate both the class and its member functions. This worked for gcc/clang, but msvc does not support this.

So now I’m stuck. I don’t really see a way to add visibility macros to the headers in a way that is portable across both Windows and Linux. We could solve this by having separate macros for the two OSes, but that seems like it would be too invasive and hard to maintain. I’ve also considered trying to use a linker script, but I’m not sure yet exactly how to do that.

I’m looking for advice on how to move forward now. Especially, if someone has solutions to the unique_ptr issue on Windows or the vtable issue on Linux.

Thanks,
Tom