John Maddock wrote:

Many many thanks for working on this, however running locally it fails for me at the linking step:

compile-c-c++ ..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug\config_info.obj clang-win.link ..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug\config_info.exe '/DEBUG' is not recognized as an internal or external command, operable program or batch file.

/DEBUG /subsystem:console /out:"..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug\config_info.exe" @"..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug\config_info.exe.rsp" ... Any ideas?

What does `b2 --debug-clang-configuration` say?

John Maddock wrote:

...

What does `b2 --debug-clang-configuration` say?

notice: [clang-win] using compiler '"clang-cl.exe"', version '6.0.0' notice: [clang-win] 32: using assembler '"D:\\compilers\\visual studio\\2017\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x86\ml.exe"' notice: [clang-win] 32: using archiver '"D:\\compilers\\visual studio\\2017\\VC\\Tools\\MSVC\\14.15.26726\\bin\HostX86\x86\link.exe" /lib' ... All of which look OK to me, no linker listed though?

Yes, seems fine. I use "clang-cl.exe /link" as the linker, and the fact that the autodetection works correctly means that "clang-cl.exe /link" works. I however note that while [clang-win] reports version 6.0.0, your actual compilation used "clang-win-6.0". Do you have something in user-config.jam left over from previous attempts?

On Fri, 16 Nov 2018 at 14:33, Peter Dimov via Boost wrote:

degski wrote:

...

On Thu, 15 Nov 2018 at 19:09, Peter Dimov via Boost wrote:

...

With the current develop branch (since Boost.Build hasn't been merged to master yet),

b2 toolset=clang-win

now works on Appveyor without additional configuration. You can see it in action at

Will your fixes related to lld be merged to master before final release?

I'm not in charge of merging Boost.Build to master, so, no idea. :-)

Who is that person then, and could we ask him/her to merge it? It's certainly a big improvement [over the state it was in] and will allow for a wider range of users to comment or submit bug reports. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

Edward Diener wrote:

But if I invoke 'b2 toolset=clang-win-6.0' against some test jam file with a user-config.jam file of 'using clang-win : 6.0 : C:/Utilities/LLVM/601/x32/bin/clang-cl ;' I constantly get:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include\yvals_core.h(294,5): error: STL1000: Unexpected compiler version, expected Clang 7 or newer. #error STL1000: Unexpected compiler version, expected Clang 7 or newer.

That's a feature of the new MSVC 15.9. 15.8 worked with clang 6.

Even if I add a 'using msvc : 14.0 ;' to my user-config.jam the same problem occurs. It seems as if clang-win always uses the latest version of vc++, which of course does not work with an earlier version of clang, as the error message shows.

Which version of VS is used by clang-cl.exe is not determined by clang-win.jam, it's decided by clang-cl.exe itself. You could try -fmsc-version=1900, I suppose.

On 11/17/2018 3:12 PM, Peter Dimov via Boost wrote:

...

Which version of VS is used by clang-cl.exe is not determined by clang-win.jam, it's decided by clang-cl.exe itself. You could try -fmsc-version=1900, I suppose.

According to

https://github.com/llvm-mirror/clang/blob/2bade23358bd718ed8ea2b5f5405ac52e1...

the only way to make clang-cl.exe use an older VS installation is to invoke it from the corresponding developer command prompt.

That works nicely. Thanks !

Edward Diener wrote:

I discovered that the clang-cl --version option only works with clang 6.0 on up, whereas the clang-cl -v option works down through clang 3.5 ( but not clang 3.4 ). Both output the exact same result AFAICS. However the --version option when clang-win captures it with SHELL "$(compiler) --version" does not show in a Windows command window whereas the -v option when clang-win captures it with SHELL "$(compiler) -v" does show in the Windows command window.

It seems that `clang -v` outputs to stderr instead of stdout. You could try SHELL "$(compiler) -v 2>&1", although this seems a bit picky. Not sure how the SHELL builtin will like it.

On 11/17/2018 3:00 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

But if I invoke 'b2 toolset=clang-win-6.0' against some test jam file with a user-config.jam file of 'using clang-win : 6.0 : C:/Utilities/LLVM/601/x32/bin/clang-cl ;' I constantly get:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include\yvals_core.h(294,5): error: STL1000: Unexpected compiler version, expected Clang 7 or newer.     #error STL1000: Unexpected compiler version, expected Clang 7 or newer.

That's a feature of the new MSVC 15.9. 15.8 worked with clang 6.

...

Even if I add a 'using msvc : 14.0 ;' to my user-config.jam the same problem occurs. It seems as if clang-win always uses the latest version of vc++, which of course does not work with an earlier version of clang, as the error message shows.

Which version of VS is used by clang-cl.exe is not determined by clang-win.jam, it's decided by clang-cl.exe itself. You could try -fmsc-version=1900, I suppose.

Even with -fmsc-version=1900 the same problem occurs and the latest vc++ is used. The most interesting thing is that if I use the usere-config.jam file of: using clang : 6.0 : C:/Utilities/LLVM/601/x32/bin/clang++ : <compileflags>-fmsc-version=1900 <linkflags>-fuse-ld=lld ; I do not get any error about an expected Clang 7 and vc++14.0 is being used.