Issue 914 in include-what-you-use: No combination of compilers or configs build for Windows
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
As title states, I’ve spent about a day attempting to compile the project for Windows 10, x64 AMD cpu.
compilers used:
msvc 2019
clang compiler for VS
clang-12
Generators:
Ninja
Visual Studio
paths to LLVM:
LLVM 12 compiled from source and installed with all the packages, eg “clang, clang-tools etc”
clang from source, ie pointing to the. `llvm/build` As per docs
Does anyone have an idea as to how to make this happen?
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
I no longer have access to a Windows machine, so Windows support is basically me fumbling around in the dark these days :-)
Can you be more specific around what you've done and what the problems were?
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
https://gist.github.com/whb07/c4de47d8d7bf10930057155974460c89
Sure here is 3 entire build logs using clang, msvc, and gcc.
These builds were done pointing the CMAKE_PREFIX_PATH to my locally build LLVM project that was installed at the location noted. I'm compiling Clang now and going to have it point instead to the local build path to see if that changes anything.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
https://gist.github.com/whb07/c4de47d8d7bf10930057155974460c89
Sure here is 3 entire build logs using clang, msvc, and gcc.
These builds were done pointing the CMAKE_PREFIX_PATH to my locally build LLVM project that was installed at the location noted. I'm compiling Clang now and going to have it point instead to the local build path to add more logs to that gist file.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
As far as I can tell, most of these errors are from LLVM headers. There's probably something in LLVM's build system that masks/fixes them, but is not exported to CMake consumers of their build.
* `error: use of typeid requires -frtti`: https://stackoverflow.com/questions/47950690/
* `error: expected a qualified name after 'typename'`: this is because windows.h has `#define CALLBACK __stdcall`. Should be possible to patch that in LLVM by renaming the `CALLBACK` template argument or using `#pragma push_macro` to temporarily undefined `CALLBACK`.
* `../iwyu.cc:2001:19: error: no member named 'CK_MatrixCast' in namespace 'clang'` -- this is a version compat problem. You need to build IWYU against a LLVM/Clang version that's compatible. Unfortunately I haven't taken a 12 branch for IWYU yet, so there may not be a compatible version. I'll try to do so shortly.
* `<command-line>: warning: "_FILE_OFFSET_BITS" redefined`: Not sure why this happens with GCC, looks like `-D_FILE_OFFSET_BITS=...` is added multiple times to the compile command. We don't add that in IWYU, so this may be fixable in LLVM. Or the warning should just be disabled.
* `error: 'mutex' in namespace 'std' does not name a type`: This is strange. It indicates that the compiler does not use a C++11 compatible mode. Latest IWYU explicitly passes `-std=c++14`, so I wonder how that happens.
* `overriding '/EHs' with '/EHs-'`: this looks like LLVM now adds flags to set exception handling semantics, and IWYU does too. I think that can be removed from IWYU to avoid confusion. I'll draft a change, and maybe you could help me test it.
* `C:\Program Files\LLVM\include\clang/Analysis/CFG.h(1380,3): <numerous errors>`: Not sure what's going on here, but it also seems like something that needs to be addressed in LLVM.
So all in all, if you use MSVC to build, that seems to work best (which is kind of surprising, but nice :-)) -- I suspect the problem you're seeing in `CFG.h` is because IWYU happens to include `Shlwapi.h` before `CFG.h` and the former `#define`s some name that is used in the latter.. You can probably patch around that locally by `#undef-ing` whatever is causing problems in `iwyu_port.h` (like is done with `interface`).
Or it could also be that the MSVC STL includes `<windows.h>` transitively somewhere, so this needs to happen later, just before including LLVM headers.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
@kimgr So what you saw is llvm-12, with what i presume are the latest versions of each compiler, and yes clang-12. If i recall correctly, I did even attempt to compile different versions to no avail.
Do you have a recollection of a setup that worked on windows? I can help you out if need be, I sometimes run windows inside of virtualbox/vmware on my osx machine when I need a quick look around.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
The compiler versions aren't particularly important as long as they're a version supported by llvm. I think they have documentation around that somewhere on llvm.org.
I don't think llvm-12 and iwyu trunk are 100% compatible; that MatrixCast was added after the 12 branch was taken, IIRC. You can always try and create a local branch with the compensating iwyu commit reverted.
Besides that, there's probably some tinkering with `CMAKE_CXX_FLAGS` you can do to work around most of the issues.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
> Do you have a recollection of a setup that worked on windows?
When I did Windows development, I first used the (now-unsupported) in-tree build, where the IWYU tree was checked out inside the Clang tree (in what is now `llvm-project/clang/tools/`) and Clang's CMake system was manually patched to add IWYU as a subdir.
But I think I did some work with the out-of-tree mode as well, as documented in the README.
I don't think anything is fundamentally broken on Windows, I think we just need to find the quirks to address in both LLVM and IWYU (see bullet list above). I can try and get to branching and fixing up the exception flags tonight (EST), but it would be nice if you could try and patch your local LLVM (or IWYU, if that's easier) to solve the others.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
I'm able to help if we can coordinate properly. I am not really too aware of the LLVM internals and I am a playful tourist with C++. Perhaps you could point me to what I could patch locally? I can also work on trying to run LLVM11 and the matching branch for IWYU.
On a side note, whats the status of CI for this project? Are there different OS/architectures being tested? I know I recently tried compiling for osx-bigsur(?)/x86_64 and was unable to get a clean build going hassle free.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
> Unfortunately I haven't taken a 12 branch for IWYU yet, so there may not be a compatible version. I'll try to do so shortly.
I just pushed a `clang_12` branch to https://github.com/include-what-you-use/include-what-you-use.
> overriding '/EHs' with '/EHs-': this looks like LLVM now adds flags to set exception handling semantics, and IWYU does too.
> I think that can be removed from IWYU to avoid confusion. I'll draft a change, and maybe you could help me test it.
I posted a PR with this change: https://github.com/include-what-you-use/include-what-you-use/pull/924.
Could you create a testing branch from the `clang_12` branch, cherry-pick this PR commit onto it and see if that works for you with regard to `CK_MatrixCast` and `overriding /EHs with /EHs-` on Windows/MSVC? Thanks!
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
> On a side note, whats the status of CI for this project? Are there different OS/architectures being tested? I know I
> recently tried compiling for osx-bigsur(?)/x86_64 and was unable to get a clean build going hassle free.
Currently only Linux because that's the only platform where our test suite is 100% functional. Other platforms have expected or known failures. See https://github.com/include-what-you-use/include-what-you-use/blob/master/.github/workflows/ci.yml for details.
But it would be nice to get a build going at least, to catch simple portability issues.
If you (or someone else) knows how to set up a Windows and/or Mac build as a GitHub Actions workflow, I'd be happy to consider it.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
> I'm able to help if we can coordinate properly. I am not really too aware of the LLVM internals and I am a playful tourist
> with C++. Perhaps you could point me to what I could patch locally? I can also work on trying to run LLVM11 and the
> matching branch for IWYU.
Not sure what kind of coordination you mean, but I'm all for it :).
I thought the bullets in https://github.com/include-what-you-use/include-what-you-use/issues/914#issuecomment-846422257 were pretty straightforward. With the `clang_12` branch and the patch for the `/EHs` warning your only remaining issue should be the `CFG.h` problem.
I dug out `Analysis/CFG.h` in my local clang-12 tree, and line 1380 is:
```
template <typename CALLBACK>
void VisitBlockStmts(CALLBACK& O) const {
for (const_iterator I = begin(), E = end(); I != E; ++I)
for (CFGBlock::const_iterator BI = (*I)->begin(), BE = (*I)->end();
BI != BE; ++BI) {
if (Optional<CFGStmt> stmt = BI->getAs<CFGStmt>())
O(const_cast<Stmt*>(stmt->getStmt()));
}
}
```
As I mentioned earlier, `CALLBACK` is hijacked with a define in Windows headers to something like `#define CALLBACK __stdcall`, which breaks this code.
So there are two "solutions":
* Send a patch to LLVM to avoid the word `CALLBACK` because Windows is a big platform, and it would be good if they played nice together
* `#undef CALLBACK` in IWYU before this header is included. I'd first try in `iwyu_port.h` just after `#undef interface`, but there's no guarantee that some other header doesn't also pull in Windows headers, so it might not help. Give it a shot and let me know what falls out.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/issues/914
> Send a patch to LLVM to avoid the word CALLBACK because Windows is a big platform, and it would be good
> if they played nice together
Hah, turns out this is already fixed on LLVM mainline:
```
commit 54bff1522fc863329894d875d54c2fe4cd1b4f3f
Author: Zachary Henkel
Date: Tue May 4 11:19:54 2021 -0400
Rename a template parameter that conflicted with a common macro; NFC
The CALLBACK macro is used extensively in the Windows SDK.
```
So if you can switch to LLVM+Clang 13 and test with my https://github.com/include-what-you-use/include-what-you-use/pull/924, the MSVC build looks like it might work.