Page MenuHomePhabricator

Enable building LLVMgold.dll under mingw.
ClosedPublic

Authored by srhines on Aug 24 2017, 11:47 AM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

srhines created this revision.Aug 24 2017, 11:47 AM

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 accepted this revision.Aug 27 2017, 6:17 PM
chapuni added a subscriber: 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?

This revision is now accepted and ready to land.Aug 27 2017, 6:17 PM

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).

@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, 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.

This revision was automatically updated to reflect the committed changes.