These don't build in MSVC at the moment, so filter these out altogether
from the list of runtimes and print a warning.
Details
Diff Detail
Event Timeline
I'm not sure if there's a better way. I cannot remove these from LLVM_ENABLE_RUNTIMES since I still want to build these for other targets, but I don't want these for Windows because they break the build.
Just for clarity, can you clarify in the subject that this is for windows/msvc (as I see in the code that you keep allowing building them for mingw - thanks for that!).
(I still only build these libs as standalone builds myself, but maybe I'll have time to try integrated building at some point.)
We added support for overriding LLVM_ENABLE_RUNTIMES on a per-target basis for this exact reason in D67195. Does that work for you?
(I want to generalize that support a bit, but it should already work for LLVM_ENABLE_RUNTIMES.)
Not out-of-the-box because that filter is only used for explicit targets, not for the "default" builtins and runtimes (i.e. host) which is what we currently use on Windows and Darwin.
In that case, looks good with the condition changed to MSVC.
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
30–31 | I think MSVC is a better condition here than WIN32 AND NOT MINGW, since libunwind and libc++abi aren't compatible with the MSVC ABI. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
30–31 | Done, I've also added a warning so it's easier to spot in the output. |
Hello @phosek,
these changes break the ARM cross builders on Windows:
http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/4240
also it suppresses building of the libraries on the Aarch64 cross builder http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64
We use "just built" clang toolchain to build the runtime/builtin libraries there. These changes do not allow using the toolchain in case it was built by MSVC.
Would you fix it or revert the commit?
Hello @phosek,
the builders are broken for the third day in a row.
Sorry, but I'm going to revert this commit.
No worries and sorry about the late response, I missed your earlier message. I'll take a look into this issue.
I think MSVC is a better condition here than WIN32 AND NOT MINGW, since libunwind and libc++abi aren't compatible with the MSVC ABI.