Edward Diener wrote:

On 8/11/2018 6:22 PM, Peter Dimov via Boost wrote:

...

Has anyone succeeded in getting clang-cl.exe working under b2? I've installed llvm-6.0.1, added it to PATH, put

using clang-win : : : <compatibility>vc14 ;

I use this:

using clang : 6.0cl : C:/Utilities/LLVM/601/x32/bin/clang++ : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1900 <compileflags>--target=i686-pc-windows-msvc <linkflags>--target=i686-pc-windows-msvc <linkflags>-fuse-ld=lld ;

This kind of works, even without the options, using just the simple using clang ; and without setting up any MSVC build environment. clang++ finds MSVC 2017 on its own. But unfortunately any dynamic_cast use fails with undefined symbol: __imp___RTDynamicCast regardless of whether I use -fuse-ld=lld. :-/

On Sun, 12 Aug 2018 at 04:52, Edward Diener via Boost wrote:

I agree. It is not very good. In general clang under Windows, whether using gcc or vc++ has many problems

I don't understand what you mean with this, you are using clang and lld, and you arer talking about gcc and vc?

, but almost always with the linker and rarely with the compiler, although it still can not handle VMD with its preprocessor. I gave up trying to get the clang developers to pay any attention to any of this a while ago.

Clang 7.0 RC is out, other than the filesystem thing, there don't seem to be many issues. You could give that a spin. I always use trunk and there are improvements (also in constexpr f.e.). degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

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

On Sun, 12 Aug 2018 at 16:18, Edward Diener via Boost wrote:

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.

I'm not saying Boost.Config does not identify Clang on Windows correctly. The problem lies in the various libraries dealing with this information. The build does mention a lot of linux refs though, so even there I'm not so sure. I get things like C:\boost-build\boost\bin.v2\libs\atomic\build\clng-lnx-8.0.0\rls\lnk-sttc . It certainly looks suspicious, but heck 26 libraries do build. We don't all love the broken VC++ emulated preprocessor of clang with

vc++ as you do.

I don't love it, but writing modern C++17 doesn't need much pre-processing, so that's what I try to do. 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.

I'm outside the gate too, so no. I've been writing about this for long time now, but it gets mostly ignored. To prove that point: I posted this https://lists.boost.org/Archives/boost/2018/07/242444.php on the 8th of Juli. Nobody answered that and that question has as it turns out yesterday (from a post by that same Peter) to be a very simple answer, thanks Peter!. In the meanwhile I already deleted the stuff to what that was relevant.

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 -- *"If something cannot go on forever, it will stop" - Herbert Stein*

On Sun, 12 Aug 2018 at 21:21, John Maddock via Boost wrote:

There are currently only 4 type_traits tests that fail with clang/llvm on windows - all related to msvc compatibility.

The (type of) errors I refer to is where f.e. std::is_assignable is clearly available on compiler/platform but the boost one is reported not found, while the obvious std::is_assignable (that should be used) is not used. This was in wave, but I'm sure there are more of the same type of errors as the above, they probably all just need 1 fix, i.e. it's a class of errors. Wasn't this the/a similar symptom in Regex, it's too long ago cannot remember. There the reason was that the detection was too simple, for the now more complex situation that has been created (by the arrival of Clang/VC STL). Just checking for _MSC_VER no longer does the Job, there needs to be a check for __clang__ and/or possibly __GNUC__ depending on what one is trying to determine. I'll build again saving the build output to file and do some diggin'. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

degski wrote:

.\boost/type_traits/has_trivial_move_assign.hpp:49:4: error: no template named 'is_assignable'; did you mean 'std::is_assignable'? BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T)

FWIW, this seems to be because BOOST_HAS_TRIVIAL_MOVE_ASSIGN is defined under Clang as: # define BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T) (__is_trivially_assignable(T&, T&&) && is_assignable::value && !::boost::is_volatile<T>::value) but then the headers for is_assignable or is_volatile aren't included.

On Mon, 13 Aug 2018 at 15:55, Peter Dimov via Boost wrote:

degski wrote:

...

I think in all honesty that the whole concept is wrong, clang/llvm on windows should be treated as if it were vc (invoking clang-cl) and not as some spin-off of linux-clang, which seems to amount to try getting a square peg into a round hole. So, we should not have clang-win, but msvc-clang as a target.

That's exactly what clang-win does, it's a msvc-lookalike that uses clang-cl. But it doesn't work. So we use clang-linux, which kind of works, except for dynamic_cast.

I don't care either way, whatever works. In the end of the day, I'd like the linux-clang better as it is far clearer what it does or what it doesn't (and I can look it up consulting the gnu docs), I'm with you here. The dynamic_cast for some weird reason does not work/link, I saw exactly what you saw. Some incantation is just simply wrong. On the other hand, what seems to be lost to everybody (except some clang people) is that clang.exe, clang++.exe, clang-cpp.exe, clang-cl.exe (and the now removed cl.exe in the clang distribution) are just copies of the exact same binary, their hash values confirm this (please check if you doubt what I'm saying). They just behave differently, because they are named differently, I'm sure anyone understands that doing that is not rocket-science, you can do this in C. So passing options to the linux-facade (or the real thing, whatever you'd like to call it) using the -Xclang prefix in clang-cl really just passes flags/parameters to the exact same binary, gnu style. So knowing this, my point is that since vc builds Boost without a problem, clang-cl should build Boost without a problem as well, while nothing stops anyone from passing in other options (directly to "the real thing") using the -Xclang prefix. This is the main reason I don't care, coz I know, it's really the same thing. I also think that this is the main reason the clang-crew is un-responsive, because they know the problem is in the incantations. But, I'm (really) happy we seem be get closer to the problem, at some point we will solve the conundrum. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

On Mon, 13 Aug 2018 at 16:43, Peter Dimov via Boost wrote:

degski wrote:

...

So knowing this, my point is that since vc builds Boost without a problem, clang-cl should build Boost without a problem as well,

Sure, the problem with the clang-win.jam toolset is not with Clang, it (meaning clang-win.jam) just doesn't work for some reason.

Now, let's try find out why it doesn't. I was proposing to approach it from the other direction, because somehow we seem to have hit a (hitherto) unknown stumbling block approaching the problem from this (the linux-clang) end. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

Hi, Is it possible to setup and add clang-win (clang-win-7.0) into test matrix for the 1.69 release? Several libraries still must be tweaked for it - boost.preprocessor has build errors, maybe others. -- Egor Pugin

Do you mean clang on Windows targeting vc++ or clang on Windows targeting mingw-64/gcc ?

clang-vc++ aka clang-cl In other words clang in VC++ compat mode. -- Egor Pugin

I have this in user-config.jam for clang 7.0 on Windows targeting vc++

Sure, but is it possible to add such config to develop/master tables? :) Here - https://www.boost.org/development/tests/develop/developer/summary.html -- Egor Pugin

On Wed, Oct 24, 2018 at 6:37 PM Egor Pugin via Boost wrote:

...

I have this in user-config.jam for clang 7.0 on Windows targeting vc++

Sure, but is it possible to add such config to develop/master tables? :) Here - https://www.boost.org/development/tests/develop/developer/summary.html

Yes, it's possible. *You* could do it by following the instructions here < https://www.boost.org/development/running_regression_tests.html>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On 10/25/2018 3:56 AM, degski via Boost wrote:

On Thu, 25 Oct 2018 at 00:53, Edward Diener via Boost wrote:

...

On 10/24/2018 6:33 PM, Egor Pugin via Boost wrote:

...

...

Do you mean clang on Windows targeting vc++ or clang on Windows targeting mingw-64/gcc ?

clang-vc++ aka clang-cl In other words clang in VC++ compat mode.

I have this in user-config.jam for clang 7.0 on Windows targeting vc++ ( VC++ compat mode ) :

using msvc ;

using clang : 7.0 : C:/Utilities/LLVM/700/x64/bin/clang++ : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1900 <compileflags>--target=x86_64-pc-windows-msvc <linkflags>--target=x86_64-pc-windows-msvc <linkflags>-fuse-ld=lld ;

You are calling clang++.exe, I doubt this invokes a vc-compatible compiler. From what I have seen is that this approach creates some weird linux/vc chimaera (all the build paths have some linux reference in it). I'm not saying [Peter also seems to have this approach] that this [having compatibility mode on] is required, you're indicated progress in the PP-realm seem to confirm that.

My understanding, from having previously been active asking questions on the clang developers mailing list, is that there is absolutely no difference between clang targeting vc++, which the "--target=" does above for the compile and the link, and clang-cl. In fact if you look at a release of LLVM on Windows, which in recent builds defaults to targeting vc++, you will see that the clang-cl.exe is exactly the same size as the clang++.exe.

When Boost-1.69-rc comes out I'll waste a few more hours of my life trying to compile Boost with Clang, I'll keep you updated. If and when you give it another try, I would pass on the advice (and more or less request) from STL, that is to actually use VC-15.9 (yes, that's preview) cleanly installed, as mixing the old (14.0) and the new, we won't be able to get to the bottom of it.

For clang 7.0 I did change to use VS2017 rather than the previously mentioned VS2015. This also means -fmsc-version=1915 for vc++ 14.1.

I also add C:\Utilities\LLVM\700\x64\bin first in my PATH and I manually

...

invoke:

"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64

before the b2 invocation using toolset=clang-7.0.

It is possible that neither of these extra actions are needed.

Your setup is migrated from VS2015. In a clean install of VS2017, "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" does not exist.The correct path (for x64 host targeting x64) is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat". If you use the shortcuts in the menu [Windows Key], this problem is solved for you.

You'll need to open a developer command prompt, as, if not, clang (any clang) will have a hard time locating the VC-STL and other required libraries in the "windows kits" [8.1 or 10.0]. You could/can also add the [clang] path afterwards [after opening the build prompt] with 'set PATH="C:\Utilities\LLVM\700\x64\bin";%PATH%'. Both these actions are required.

I did change to manually invoke vcvars64.bat and, as already explained in my original response, I always have the appropriate clang bin directory first in my PATH.

Also possible might be to use the -fmsc-version=1915 for vc++14.1 and

...

invoke the vcvarsall,bat for Microsoft Visual Studio 14.1.

The version you put is only relevant if Boost actually does something with the supplied information. In the meanwhile _MSC_VER should give the correct info.

The -fms-compatibility compiler option is a clang switch ( https://clang.llvm.org/docs/MSVCCompatibility.html ). I do not think Boost Build does anything with it.

degski

On 10/25/2018 11:10 AM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

My understanding, from having previously been active asking questions on the clang developers mailing list, is that there is absolutely no difference between clang targeting vc++, which the "--target=" does above for the compile and the link, and clang-cl. In fact if you look at a release of LLVM on Windows, which in recent builds defaults to targeting vc++, you will see that the clang-cl.exe is exactly the same size as the clang++.exe.

The difference on the clang side is only that clang-cl accepts cl command line options.

The difference on our side is that clang-cl uses clang-win.jam, derived from msvc.jam, and clang++ uses clang-linux.jam, derived from gcc.jam. So it's not the same.

I have rued the day I pushed clang-win.jam from someone elses posting because I wanted to test clang under Windows and it seemed to work. Mainly because I am not knowledgeable enough with bjam to "fix" clang-win.jam and no one else was ever interested in doing so. With that said using clang on Windows works reasonably well for me without having to use clang-cl, but whether targeting gcc or vc++ clang on Windows has remained problematical in the linking phase for nearly every clang release. I am now trying clang 7.0 to see if it is better.

On 10/25/2018 5:53 PM, Egor Pugin via Boost wrote:

...

With that said using clang on Windows works reasonably well for me without having to use clang-cl

I'm not building using b2 and see lots of errors related to boost.pp when used in boost.log. Both for clang-cl and clang++ (v8 from today's trunk). Tried different options, nothing is helpful enough. I assume errors are probably with my compiler options/definitions. Btw, 'clang++-8 -v' shows that it turns on msvc compatibility (which is detected on system) by default.

I have not attempted to build clang-8.0 under Windows. I ran into too many errors in the past attempting to build clang on Windows, which were ignored when I mentioned it on the clang developers list, to want to keep pursuing another attempt. When I run the preprocessor tests using b2 with my toolset clang-7.0 targeting VC++ I get no errors at all, so I really do not know what you are seeing or what you are doing to produce "lots of errors". I am working with the 'develop' branch of Boost Preprocessor.

On 10/26/2018 4:04 AM, degski via Boost wrote:

On Fri, 26 Oct 2018 at 01:37, Edward Diener via Boost wrote:

...

I have not attempted to build clang-8.0 under Windows. I ran into too many errors in the past attempting to build clang on Windows, which were ignored when I mentioned it on the clang developers list, to want to keep pursuing another attempt.

It has become clear [following discussions on the cfe-dev mailing list] that vc/msbuild do(es) not scale well [enough] to build Clang/LLVM. The recommended [and what more or less seems to be the only way] is to use the combo Ninja/Cmake/VC. There are some spells [see llvm web-site] you could utter that allows you to bootstrap Clang with VC and then build Clang with the [that] latest Clang.

In the past when I tried to build clang from source under Windows I used the Ninja/CMake/mingw-64/gcc chain to build. Sometimes I was successful but many times there were errors and my efforts to try to find out what was wrong on the clang user and developer mailing lists came to nothing.

When I run the preprocessor tests using b2 with my toolset clang-7.0

...

targeting VC++ I get no errors at all, so I really do not know what you are seeing or what you are doing to produce "lots of errors". I am working with the 'develop' branch of Boost Preprocessor.

As far as I read, Edward said there were 2 errors, one of which he thought, could be ignored.

Not with clang. The errors I mentioned, in anoter thread, were with vc++ 14.1 using the new vc++ preprocessor with the /experimental:preprocessor switch.

degski

On Fri, 26 Oct 2018 at 01:37, Edward Diener via Boost wrote:

I have not attempted to build clang-8.0 under Windows. I ran into too many errors in the past attempting to build clang on Windows, which were ignored when I mentioned it on the clang developers list, to want to keep pursuing another attempt.

Is there any particular reason that you cannot use the binaries that are available for download from llvm.org? You seem to focus on a problem that has some interest, but that now stops you from seeing the problem(s) there is(are) with building boost with clang [which binary is doing that seem rather irrelevant to me]. degski - *“If something cannot go on forever, it will stop" - Herbert Stein*

On 10/26/2018 3:57 AM, degski via Boost wrote:

On Thu, 25 Oct 2018 at 18:42, Edward Diener via Boost wrote:

...

With that said using clang on Windows works reasonably well for me without having to use clang-cl, but whether targeting gcc or vc++ clang on Windows has remained problematical in the linking phase for nearly every clang release. I am now trying clang 7.0 to see if it is better.

If you want to use Clang, targeting gcc [which I guess means that you are using MinGW], you should build Clang [clang++] with[in] MinGW and use it there.

There is no need to try and do that. Earlier releases for Windows were built targeting gcc, not vc++. It was only with later releases that the default build of clang for Windows targeted vc++. But whatever the default build of clang for Windows targeted you could always use the compile/link -target switch to change it at runtime.

What we [or I at least] am talking about is using Clang as a native windows compiler [a drop-in for cl.exe], please don't keep on mixing up those very different things [name mangling keeps getting in the way of mixing "gcc-targets" with "vc-targets"].

Aside from the use of different jam files for clang and clang-cl, and the fact that clang-cl allows vc++ like options, clang-cl and clang targeting vc++ work exactly the same.

If you wouldn't mix things up, there would not be any linking issues, as out-of-the-box clang-cl will use link.exe [the vc-linker]. Using lld with clang [beit ++, -cl or just plain clang] works perfectly fine as well.

I have experienced some linking issues when running Boost tests for various libraries for nearly every release of clang. John Maddock also brought this up in a past thread. If you had a solution for the linking issues that worked I did not see it.

Other than the above gcc-targeting I don't see what [for you] comes in the way of proper correct working linking [it works for the rest of us]. I doubt clang-7.0 brings any relief in solving your problem, because the changes in clang are not at that [basic] level, it also always worked fine with clang-6, clang-5, clang-4, clang-3.9 and clang-3.8 [in respect of the latter two, the number of ICE's were rather prohibitive for anything over "Hello world.", though].

Again this is your experience but not mine.

degski

On 10/26/2018 7:35 AM, degski via Boost wrote:

On Fri, 26 Oct 2018 at 11:44, Edward Diener via Boost wrote:

In order to get forward at all, we need to:

1. Forget about GCC! It's got nothing to do with GCC. 2. Don't call clang++.exe in the config file, as this invokes the incorrect [linux] jam.file [as confirmed by Peter].

This entire thread was started because using clang-cl with clang-win did not work for the OP. I have expressed the opinion that I have gotten clang targeting vc++, which you insist is not clang-cl in any way even though it uses the vc++ headers and libraries, to mostly work, except for some linking issues over a number of releases of clang, when testing Boost libraries. If you have a setup under Boost using clang-cl and clang-win that works in your testing of Boost libraries please present that setup in the form of jamfile code. Otherwise we are discussing this to no purpose. The latest correspondent asked in this thread for some setup that would work and I gave to him what works for me best using clang.

degski

On 10/26/2018 8:44 AM, degski via Boost wrote:

You're actually saying it doesn't work, you are bringing up linker issues, but I think there are more issues. But as I say, until you just download a Clang binary [the windows one: https://prereleases.llvm.org/win-snapshots/LLVM-8.0.0-r339319-win64.exe or https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe] and go on and try build Boost with Clang, we are all just looking at spaghetti on the wall.

What makes you think I have not downloaded and installed clang binaries ? All of my setups for using clang on Windows have involved downloading and installing binaries. As others on this thread have expressed there are problems using clang on Windows to test Boost libraries. I have given what setup works for me best.

degski

On 10/26/2018 9:18 AM, degski via Boost wrote:

On Fri, 26 Oct 2018 at 14:57, Edward Diener via Boost wrote:

...

What makes you think I have not downloaded and installed clang binaries?

You are mentioning that you have experienced problems building Clang/LLVM using GCC and MinGW. Based on that I conclude that that is what you are doing [call me stupid, no probs] ... and then that makes me think that the issues you experience are related to you doing that.

All of my setups for using clang on Windows have involved downloading

...

and installing binaries. As others on this thread have expressed there are problems using clang on Windows to test Boost libraries. I have given what setup works for me best.

What works best. How do you compare best over better, if things fail? AFAICS, the only result that matters is the one that works correctly. The config you posted does [as confirmed by Peter], per design [no criticism], the wrong thing [you implicitly invoke boost-build linux stuff, what could possibly go wrong?].

Why can't you get it in your head that when you use clang targeting vc++ you have clang as the compiler using the vc++ headers and libraries creating a Windows executable, and when you use clang targeting mingw-64/gcc it uses the mingw-64/gcc headers and libraries and also produces a Windows executable. If both are not testing clang on Windows I do not know what is. If I, and obviously the OP of this thread, could get clang-cl using clang-win to work reliably I would suggest using that. But it is not my experience that the latter works very well. If that setup works for you, that is fine.

degski

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 26 October 2018 13:45 To: boost Cc: degski; Edward Diener Subject: Re: [boost] clang-win, again

On Fri, 26 Oct 2018 at 14:05, Edward Diener via Boost wrote:

The latest correspondent asked in this thread for some setup that would

...

work and I gave to him what works for me best using clang.

You're actually saying it doesn't work, you are bringing up linker issues, but I think there are more issues. But as I say, until you just download a Clang binary [the windows one: https://prereleases.llvm.org/win-snapshots/LLVM-8.0.0-r339319-win64.exe or https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe] and go on and try build Boost with Clang, we are all just looking at spaghetti on the wall.

I'm following this discussion with interest and I want to use Clang on windows with VS, or Clang Codeblocks using Mingw - which works but is less suitable for big tests, so most of all with b2/bjam so I can write using toolset=MSVC,GCC,Clang ... I'd also want to use the binary release like https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe, so I think any effort should be directed at that. We seem to be so near and yet so far. I sense that the jam files are the key. Paul

On Fri, 26 Oct 2018 at 16:36, Peter Dimov via Boost wrote:

... and extract the path to link.exe from there...

You questioned the wisdom [or stupidity] of running the boost build from a VC developer command prompt before, AFAICR. Well this is one, open a dev-command-prompt and link.exe is in the path [plus everything else]. But it would in reality be more interesting to use lld, IMO. On the other hand, I have not a single dll amongst my libs, and this never is a problem, so again I'm puzzled. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

You can try the attached clang-win.jam, with

Using your config I got several errors related to .asm files with b2. See https://pastebin.com/RXih1XyB --- Also I found the root cause of my issue. My build system added VC include paths to command line: "-IC:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/include" "-IC:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/ATLMFC/include" If I add these lines, for example, to bin.v2\libs\log\build\clang-vc14.1-win-cl6\release\address-model-64\link-static\threadapi-win32\threading-multi\syslog_backend.obj.rsp it does not compile. Without them, everything is fine. Seems like some internal clang-cl issue. -- Egor Pugin

AMDG On 10/27/2018 07:07 AM, Peter Dimov via Boost wrote:

Also, Math's precompiled headers don't seem to work, I get

clang-cl.exe: warning: support for '-Yu' without a corresponding /FI flag not implemented yet; flag ignored [-Wclang-cl-pch]

clang-cl.exe: warning: argument unused during compilation: '-Fpbin.v2\libs\math\build\clang-win-6.0.1\release\link-static\threading-multi\pch.pch' [-Wunused-com mand-line-argument]

I probably need to figure out a way to disable them.

It should be enough to exclude the pch generators from toolset.inherit-generators. In Christ, Steven Watanabe

Latest iteration attached.

For some reason nothing is changed for .asm files. Still those errors like ml/ml64 were not found or selected. Should I call vcvars32/64 before building? Now I invoke on fresh cmd with updated clang-win.jam: b2 toolset=clang-win -- Egor Pugin

You need to apply the patch

I applied it before my previous post. Asm files were changed in the output, but ml executable still missing. -- Egor Pugin

What does ... say?

https://pastebin.com/kdthbdWY -- Egor Pugin

Egor Pugin wrote:

...

https://pastebin.com/kdthbdWY

   clang-win.compile.asm bin.v2\libs\context\build\clang-vc14.1-win-cl6\...

The `clang-vc14.1-win-cl6` part indicates to me that you have something in your user-config.

When I issue

   b2 --debug-clang-configuration --with-context toolset=clang-win

without having any `using clang` statements in user-config, I get diagnostic output of the form...

well, to be frank, I got

   C:/boost-git/develop/tools/build/src/tools\clang-win.jam:52: in clang-win.init from module clang-win    error: Please set <compatibility> property for visual studio version!

because I had reset my clang-win.jam to the develop one, but when I switch tools/build to pr/fix-clang-win, I get...

well, I got

   C:/boost-git/develop/tools/build/src/tools\clang-win.jam:71: in clang-win.init from module clang-win    error: Cannot configure toolset clang-win: no 'clang-cl.exe' command found or given

because I forgot to add llvm to the PATH, but when I do that, I get (and this time it will work, I promise)

notice: [clang-win] configuring 'clang-cl.exe' version '6.0.1' notice: [clang-win] 32: using assembler '"C:\\Program Files (x86)\\Microsoft Vis ual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x86\ml.

exe"' notice: [clang-win] 32: using archiver '"C:\\Program Files (x86)\\Microsoft Visu al Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\HostX86\x86\link.e

xe" /lib' notice: [clang-win] 32: using SDK path 'C:\\Program Files (x86)\\Windows Kits\\1 0\\bin\x86' notice: [clang-win] 32: using manifest-tool '"C:\\Program Files (x86)\\Windows K its\\10\\bin\x86\mt.exe"' notice: [clang-win] 32: using resource-compiler '"C:\\Program Files (x86)\\Windo ws Kits\\10\\bin\x86\rc.exe"' notice: [clang-win] 32: using mc-compiler '"C:\\Program Files (x86)\\Windows Kit s\\10\\bin\x86\mc.exe"' notice: [clang-win] 32: using idl-compiler '"C:\\Program Files (x86)\\Windows Ki ts\\10\\bin\x86\midl.exe"' notice: [clang-win] 64: using assembler '"C:\\Program Files (x86)\\Microsoft Vis ual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\ml6

4.exe"' notice: [clang-win] 64: using archiver '"C:\\Program Files (x86)\\Microsoft Visu al Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\\lin

k.exe" /lib' notice: [clang-win] 64: using SDK path 'C:\\Program Files (x86)\\Windows Kits\\1 0\\bin\x64' notice: [clang-win] 64: using manifest-tool '"C:\\Program Files (x86)\\Windows K its\\10\\bin\x64\mt.exe"' notice: [clang-win] 64: using resource-compiler '"C:\\Program Files (x86)\\Windo ws Kits\\10\\bin\x64\rc.exe"' notice: [clang-win] 64: using mc-compiler '"C:\\Program Files (x86)\\Windows Kit s\\10\\bin\x64\mc.exe"' notice: [clang-win] 64: using idl-compiler '"C:\\Program Files (x86)\\Windows Ki ts\\10\\bin\x64\midl.exe"' Performing configuration checks

and so on, with the directory of the intermediate files being clang-win-6.0.1, which matches my LLVM version. I have merged Peter's fix for clang-win.jam, from a PR he created, to Boost Build's 'develop' branch. Thanks, Peter, for working on this ! This will make it easier for others who participated on this thread to

On 10/27/2018 8:09 PM, Peter Dimov via Boost wrote: try his update.

On Tue, 30 Oct 2018 at 02:01, Edward Diener via Boost wrote:

I have merged Peter's fix for clang-win.jam, from a PR he created, to Boost Build's 'develop' branch. Thanks, Peter, for working on this ! This will make it easier for others who participated on this thread to try his update.

I'm building from the dev-head. I get this: clang-win.archive c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib if exist "c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib" DEL "c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib" C:\Program Files\LLVM\bin\llvm-ar.exe /nologo /out:"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib" @"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib.rsp" 'C:\Program' is not recognized as an internal or external command, operable program or batch file. So this C:\Program Files\LLVM\bin\llvm-ar.exe does not seem to work, and gets cut down to 'C:\Program', i.e. it's not properly quoted. This would confirm what Peter said, that he cannot build static libs. I do seem to get all the .obj files (i.e. stuff compiles), but it's messy. Just for information. On Windows, for a while [approx. 20+ years] there is the xcopy command. It [can] copies whole file-trees [with 1 command], and can do so selectively (f.e. only copy when the source file is newer than the destination file), it is also possible to make xcopy shut up about what it copies. It would be helpful to stop doing all the unnecessary copying [in the build] and also stop all the useless output, which [the output] makes it extremely hard to see what's actually going on. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

On Tue, 30 Oct 2018 at 16:06, Peter Dimov via Boost wrote: I have this project-config.jam using clang-win : : : <compatibility>vc14 <compileflags>-fmsc-version=1915 <ranlib>"C:\\Program Files\\LLVM\\bin\\llvm-ranlib.exe" <archiver>"C:\\Program Files\\LLVM\\bin\\llvm-ar.exe" <rc>"C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.17763.0\\x64\\rc.exe" <compileflags>--target=x86_64-pc-win32 <linkflags>--target=x86_64-pc-win32 <linkflags>-fuse-ld=lld <linkflags>-flto=thin <architecture>x86 <address-model>64 <link>static <runtime-link>static ; and then I make this call: b2 -a -d+2 -j2 -o%HOME%\clang_log_debug.log "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=debug threading=multi --abbreviate-paths --prefix=%PREFIX% --build-dir=c:\boost-build --without-python --without-mpi --without-math --disable-filesystem2 install In my setup, Clang/LLVM (/bin) is in my PATH. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

On Tue, 30 Oct 2018 at 16:41, Peter Dimov via Boost wrote:

Yeah, you'll need to delete all that. Either just `using clang-win ;` or nothing at all.

So where to add any options/commands? On the command line? The quoting issue is interesting; I do quote the command, which quoting I

left from the previous clang-win.jam, but I don't quote the options such as <archiver>, because msvc.jam doesn't either. It probably needs to be consistent, but I'm not sure which way consistent.

Not only is it not quoted, but the escape is gone as well. If you are able to build all, correctly, could you please post a recipe, like do this, do that... I'm starting from the develop-head of a few hours ago, those (your) PR's are in there. I have the latest VC-15.8.8, I'm on Win10-1809, including the CRT's. I would like to build static libs, x64, statically linked with/instrumented for lld and thin-lto, optimized for broadwell (release and debug). degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

On Tue, 30 Oct 2018 at 17:18, Peter Dimov via Boost wrote:

...

If you are able to build all, correctly, ...

I can, but I don't use lld or thin-lto.

You should try ThinLTO http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html, it can generate wildly better binary code [and Clang/llvm does not implement VC's LTO]. For being able to benefit, you'll need lld https://clang.llvm.org/docs/ThinLTO.html, though. That's a bit odd because clang-win is basically clang-cl.exe, which is the

cl.exe-compatible driver, and you'll be trying to use decidedly non-cl.exe things.

As you can spot in the docs https://clang.llvm.org/docs/ThinLTO.html , clang-cl is specifically mentioned in relation to ThinLTO and lld. But you can try with your config, I suppose. Use

<archiver>"\"C:\\Program Files\\LLVM\\llvm-ar.exe\""

for now, to manually quote it.

I'll try that. --target, <architecture>, <address-model> shouldn't be needed.

How do I get 64-bit binaries then? As Edward pointed out at length, clang, clang-cl and clang++ are the same binary. You can pass gcc-like options "through" clang-cl, using the -Xclang prefix, f.e. '-Xclang -fforce-enable-int128', will make gcc-style 128-bit ints available on Windows (targeting VC, to keep the ED-speak). degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

degski wrote:

...

<rc> too.

rc, the resource compiler, are you sure that's not a valid Windows-thing?

<rc> is an option of the gcc toolset: https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L73 and so is <ranlib>: https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L66 So, these are what clang-linux.jam uses, as it's gcc based. Whereas the msvc.jam name for this option is <resource-compiler>: https://github.com/boostorg/build/blob/develop/src/tools/msvc.jam#L109 and, since clang-win is msvc-based, I've used the latter. Your whole configuration was for clang-linux, but you tried to use it with clang-win.

How do I get 64-bit binaries then?

address-model=64 on the command line, as with msvc.

On Tue, 30 Oct 2018 at 16:06, Peter Dimov via Boost wrote:

What does --debug-clang-configuration say?

Well, lots, coz it's doing a build, but just from the beginning: C:\boost>b2 --debug-clang-configuration notice: [clang-win] configuring 'clang-cl.exe' version '8.0.0' notice: [clang-win] 32: using assembler '"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x86\ml.exe"' notice: [clang-win] 32: using archiver 'C:\Program Files\LLVM\bin\llvm-ar.exe' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< no quotes notice: [clang-win] 32: using manifest-tool 'mt.exe' notice: [clang-win] 32: using resource-compiler 'rc.exe' notice: [clang-win] 32: using mc-compiler 'mc.exe' notice: [clang-win] 32: using idl-compiler 'midl.exe' notice: [clang-win] 64: using assembler '"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\ml64.exe"' notice: [clang-win] 64: using archiver 'C:\Program Files\LLVM\bin\llvm-ar.exe' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< no quotes notice: [clang-win] 64: using manifest-tool 'mt.exe' notice: [clang-win] 64: using resource-compiler 'rc.exe' notice: [clang-win] 64: using mc-compiler 'mc.exe' notice: [clang-win] 64: using idl-compiler 'midl.exe' Performing configuration checks - default address-model : 64-bit (cached) - default architecture : x86 (cached) Building the Boost C++ Libraries. - symlinks supported : yes (cached) - C++11 mutex : yes (cached) - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached) - Boost.Config Feature Check: cxx11_constexpr : yes (cached) - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached) - Boost.Config Feature Check: cxx11_final : yes (cached) - Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached) - Boost.Config Feature Check: cxx11_lambdas : yes (cached) - Boost.Config Feature Check: cxx11_noexcept : yes (cached) - Boost.Config Feature Check: cxx11_nullptr : yes (cached) - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached) - Boost.Config Feature Check: cxx11_template_aliases : yes (cached) - Boost.Config Feature Check: cxx11_thread_local : yes (cached) - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached) - has_icu builds : no (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam. note: to suppress this message, pass "--without-graph_parallel" to bjam. - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - native-atomic-int32-supported : no (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no (cached) - addr2line builds : no (cached) - WinDbg builds : no (cached) - WinDbgCached builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : no (cached) - C++11 mutex : yes (cached) - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached) - Boost.Config Feature Check: cxx11_constexpr : yes (cached) - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached) - Boost.Config Feature Check: cxx11_final : yes (cached) - Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached) - Boost.Config Feature Check: cxx11_lambdas : yes (cached) - Boost.Config Feature Check: cxx11_noexcept : yes (cached) - Boost.Config Feature Check: cxx11_nullptr : yes (cached) - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached) - Boost.Config Feature Check: cxx11_template_aliases : yes (cached) - Boost.Config Feature Check: cxx11_thread_local : yes (cached) - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached) - has_icu builds : no (cached) - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - native-atomic-int32-supported : no (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) - libbacktrace builds : no (cached) - addr2line builds : no (cached) - WinDbg builds : no (cached) - WinDbgCached builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : no (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - nowide : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - sync : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...found 33480 targets... ...updating 2361 targets... We're cross-posting now (saw you answered, while writing). degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*