Enable building LLVMgold.dll under mingw.

[srhines]

Summary

Plugins can (and should) be enabled under mingw if we are building
libLLVM.dll, so this is just a missed case. This allows LLVMgold.dll to
be built now under mingw.

[srhines]

I should note that BUILD_SHARED_LIBS seems pretty incompatible with mingw, which is why we were looking for a better way to solve this problem. Pirama actually uncovered this missing check yesterday.

[chapuni]

Patch itself is good, as far as LLVM_BUILD_LLVM_DYLIB works for mingw dll.

@srhines, I don't think BUILD_SHARED_LIBS would be incompatible. What is your case?

[srhines]

In D37116#853732, @chapuni wrote:

Patch itself is good, as far as LLVM_BUILD_LLVM_DYLIB works for mingw dll.

@srhines, I don't think BUILD_SHARED_LIBS would be incompatible. What is your case?

BUILD_SHARED_LIBS goes far beyond what is needed for just the simple plugins, as I don't want shared libraries for all sub-components (on Windows or Linux for that matter). BUILD_SHARED_LIBS also doesn't work with mingw. I get undefined reference errors, so I am not sure how anyone works with it these days, but we have cobbled together most of a build that works, and this is the last missing piece for LTO (hopefully).

[chapuni]

@srhines, BUILD_SHARED_LIBS was working for mingw with Clang/LLVM plugins, at least till June.
(I suspended running mingw builder then)
On mingw, CMake's "add_library(MODULE)" requires dependent submodules by target_link_libraries().
It's the same if you are linking your plugin with bit LLVM.dll.

FYI, I had a stale patch for mingw to work as "Linking plugin module with unnamed DLL by lazyload, to resolve symbols provided by parent EXE". Are you interested?

[srhines]

In D37116#853740, @chapuni wrote:

@srhines, BUILD_SHARED_LIBS was working for mingw with Clang/LLVM plugins, at least till June.
(I suspended running mingw builder then)
On mingw, CMake's "add_library(MODULE)" requires dependent submodules by target_link_libraries().
It's the same if you are linking your plugin with bit LLVM.dll.

We still have to try this out on a Windows machine to make sure that all of LTO is working, but getting LLVMgold.dll building is the first step. Perhaps we aren't configuring other aspects correctly, but I still think it is better to just have one LLVM.dll instead of multiple .dll files from a packaging/distribution standpoint.

FYI, I had a stale patch for mingw to work as "Linking plugin module with unnamed DLL by lazyload, to resolve symbols provided by parent EXE". Are you interested?

I'm not sure I understand this. I really stopped working on windows ~7 years ago, and didn't even do that much Windows-specific stuff at that time either. For the Android NDK, we pretty much just ship what we can on Windows, although we are trying to do a better job now. That's why this patch is important to me.

llvm/trunk/cmake/modules/HandleLLVMOptions.cmake

 endif()
 if(LLVM_LINK_LLVM_DYLIB AND LLVM_EXPORT_SYMBOLS_FOR_PLUGINS)
   message(FATAL_ERROR "LLVM_LINK_LLVM_DYLIB not compatible with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS")
 endif()
 
 # Plugin support
 # FIXME: Make this configurable.
 if(WIN32 OR CYGWIN)
-  if(BUILD_SHARED_LIBS)
+  if(BUILD_SHARED_LIBS OR LLVM_BUILD_LLVM_DYLIB)
     set(LLVM_ENABLE_PLUGINS ON)
   else()
     set(LLVM_ENABLE_PLUGINS OFF)
   endif()
 else()
   set(LLVM_ENABLE_PLUGINS ON)
 endif()