Re: [boost] clang-win, again

Subject: Re: [boost] clang-win, again
From: degski (degski_at_[hidden])
Date: 2018-08-12 12:59:01

On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost <boost_at_[hidden]>
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.
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).

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.

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.

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.

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.

degski
-- 
*"If something cannot go on forever, it will stop" - Herbert Stein*