Re: [boost] clang-win, again

On 8/12/2018 8:59 AM, degski via Boost wrote:

On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost wrote:

...

When using clang-cl the vc++ compiler is the backend.

We must be living in parallel worlds. If you use Clang/LLVM, LLVM is obviously the backend. If you download and install https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe the backend is LLVM.

You are correct. I mixed up "backend" and "frontend".

BUT, and that's where trouble (in relation to Boost) starts, is that it will use the VC STL. There is AFAICS no particular problem with the VC STL (I'm talking current release here, 15.7.6), but there is, with the way Boost deals with it when invoked with clang as a compiler on windows (non mingw), particularly boost/type_traits, has problems. Clang signals f.e. (as it did over a year ago) is_assignable not found, did you mean std::is_assignable, YES I DO. I found this issue today, Boost.Wave does not compile because of this and so don't do 9 other libraries. I've written to the list about this issue in boost/type_traits in detail over a year ago (from memory).

I do not think these are Boost problems, but clang on Windows problems. Boost.config does identify clang as the compiler on Windows correctly, whether the frontend is VC++ libraries or mingw(-64) libraries.

It is possible to

...

use clang with mingw(-64)/gcc as the backend on Windows. In either case clang has almost always exhibited its problems in the linking stage rather than the compiler stage due to the fact that it sometimes mismatches the names it creates with the backend compiler's libraries it uses. In one case on Windows, attempting to run the VMD tests, it fails pretty miserably in the preprocessor stage whereas mingw(-64)/gcc succeeds completely.

Why would you even like to do that >, LLVM generates native code directly (as it does for Rust). Both link (the vc exe, but not with LTCG, or llvm lto, thin or full) and lld will work (lld also with lto, thin or full, if you compile the code with the correct flags). There's no reason to believe (or a need for that) it works with mingw/gcc, AFAICS. Clang is a compiler, it does not do any name matching (it eats a cpp-file and spits out LLVM-ir), the problems must be in the rest of the (your) tools.

We don't all love the broken VC++ emulated preprocessor of clang with vc++ as you do.

I gave up trying to get the clang developers to pay any attention to any of

...

this a while ago.

They are a gated community just like Boost and respond similarly, just feel welcomed and all is good.

Good. Then I am sure you will be wiling to deal with them when someone reports problems trying to use clang on Windows with Boost, as Peter has just done. Please tell us what the clang developers tell us about this latest problem. It would be greatly appreciated.

Even building clang on Windows has been problematical for a while now

...

and past appeals to clang developers about this have resulted in silence on their end of things.

I use clang/cmake/ninja, and it works AFAICS. That's what they guarantee, Clang/LLVM should build with Clang stable (the one from the download link), that's it, no more. vcpkg has llvm (including clang) as well, by the way, so if you don't want to download, or would like to add your own flavour, knock yourself out. There is also some stuff (just look it up on llvm.org) to bootstrap clang with vc and then (totally automated) build clang with the clang you just built. This works, I tried it (and succeeded) 3 days ago.

I had also used the clang/cmake/ninja toolchain to build clang on Windows from source. When it did not work due to build errors I would report the problems to clang developers. While occasionally someone would answer about some bug on the Windows side of clang development, more often there was no response. Eventually I completely stopped trying to build clang on Windows from source. Who need such headaches when developers generally don't care.

Getting clang to work on Windows has been very

...

low priority for their developers in the past. Others can spend time reporting problems about their Windows implementation to clang developers if they want, but I have given up that cause.

It seems they are very focused on the compiler and not on any tooling. Having said that, it works perfectly fine from where I'm standing. I use clang/llvm with VS17 on a daily basis without any issue, which is unsurprising [but great] as MS uses clang to check how their STL is doing.

Good for you.

degski