`b2 toolset=clang-win` now works on Appveyor
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 https://ci.appveyor.com/project/pdimov/assert/builds/20331077/job/0hux9a6mlr...
On 15/11/2018 17: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
https://ci.appveyor.com/project/pdimov/assert/builds/20331077/job/0hux9a6mlr...
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" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed clang-win.link ..\..\..\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.pdb... ...skipped <p..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug>config_info.run for lack of <p..\..\..\bin.v2\libs\config\test\config_info.test\clang-win-6.0\debug>config_info.exe... ...failed updating 2 targets... Any ideas? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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?
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' notice: [clang-win] 32: using SDK path 'D:\\Windows Kits\\10\\bin\x86' notice: [clang-win] 32: using manifest-tool '"D:\\Windows Kits\\10\\bin\x86\mt.exe"' notice: [clang-win] 32: using resource-compiler '"D:\\Windows Kits\\10\\bin\x86\rc.exe"' notice: [clang-win] 32: using mc-compiler '"D:\\Windows Kits\\10\\bin\x86\mc.exe"' notice: [clang-win] 32: using idl-compiler '"D:\\Windows Kits\\10\\bin\x86\midl.exe"' notice: [clang-win] 64: using assembler '"D:\\compilers\\visual studio\\2017\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\ml64.exe"' notice: [clang-win] 64: using archiver '"D:\\compilers\\visual studio\\2017\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\\link.exe" /lib' notice: [clang-win] 64: using SDK path 'D:\\Windows Kits\\10\\bin\x64' notice: [clang-win] 64: using manifest-tool '"D:\\Windows Kits\\10\\bin\x64\mt.exe"' notice: [clang-win] 64: using resource-compiler '"D:\\Windows Kits\\10\\bin\x64\rc.exe"' notice: [clang-win] 64: using mc-compiler '"D:\\Windows Kits\\10\\bin\x64\mc.exe"' notice: [clang-win] 64: using idl-compiler '"D:\\Windows Kits\\10\\bin\x64\midl.exe"' All of which look OK to me, no linker listed though? Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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?
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?
Ah that would be it! Removed and working fine now, thanks! John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Thu, 15 Nov 2018 at 19:09, Peter Dimov via Boost <boost@lists.boost.org> 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? degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
degski wrote:
On Thu, 15 Nov 2018 at 19:09, Peter Dimov via Boost <boost@lists.boost.org> 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. :-)
On Fri, 16 Nov 2018 at 14:33, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
On Thu, 15 Nov 2018 at 19:09, Peter Dimov via Boost <boost@lists.boost.org> 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*
On 11/15/2018 12:09 PM, 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
https://ci.appveyor.com/project/pdimov/assert/builds/20331077/job/0hux9a6mlr...
If I invoke 'b2 toolset=clang-win-7.0' against some test jam file with a user-config.jam file of 'using clang-win : 7.0 : C:/Utilities/LLVM/700/x32/bin/clang-cl ;' everything works fine. 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. 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.
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.
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.
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 !
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.
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. Nonetheless I submitted a PR to change it in clang-win as some extra output showing does not appear important to me, whereas picking up the correct version in clang-win does. A worse situation relatively is that 'clang-cl something /link' works only on clang 3.9 on up. So trying to use clang-win-3.8 does not work because of SHELL "$(compiler) -m$(addr) -### foo.obj /link 2>&1" in clang-win. However since clang 3.8 is pretty old now this is no big deal.
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/18/2018 8:52 AM, Peter Dimov via Boost wrote:
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.
Works great !
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.
participants (4)
-
degski -
Edward Diener -
John Maddock -
Peter Dimov