Boost.Build and Microsoft C2 clang
Can someone who has this working right please tell me how they persuaded Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get it to link properly? My GSoC student has tried: - Configuring clang-win, this is a no-go, C2 clang comes in GCC arguments accepting form, not MSVC arguments accepting form. And no there is no clang-cl program supplied by Microsoft. - Configuring mingw gcc but with the C2 clang executable, this compiles code okay but fails at the link stage for some reason, probably it's trying to invoke the mingw linker and we want the Microsoft linker. Any help much appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
Can someone who has this working right please tell me how they persuaded Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get it to link properly?
This is what I have in my user-config from earlier tests: using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <linkflags>-v <linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\"" ;
On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
This is what I have in my user-config from earlier tests:
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <linkflags>-v <linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;
Somehow clang decides to prepend target to the linker command: "i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe" gets called in place of "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe" Clang then complains that the program is not executable. Well, obviously, it is not. Do you know how to work around this issue? Tom
Tom Westerhout wrote:
On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
This is what I have in my user-config from earlier tests:
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <linkflags>-v <linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;
Somehow clang decides to prepend target to the linker command:
"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well, obviously, it is not. Do you know how to work around this issue?
No idea. I think that this worked before, an update to VS 2017 probably broke it. I can't find where in Clang's sources is the i686-pc-windows-msvc- prepended and why, and massaging the path doesn't help. -fuse-ld is handled here: https://clang.llvm.org/doxygen/ToolChain_8cpp_source.html#l00375
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There are other problems however, exceptions are off for some reason.
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <cxxflags>-fexceptions <linkflags>-fuse-ld=link.exe ; kind of works. This cannot be considered a serious toolset though. Why not use the LLVM Clang instead?
On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There are other problems however, exceptions are off for some reason.
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <cxxflags>-fexceptions <linkflags>-fuse-ld=link.exe ;
kind of works. This cannot be considered a serious toolset though. Why not use the LLVM Clang instead?
Why not? It's just a different front-end, isn't it? In my case, MSVC doesn't handle constexpr correctly, but Clang does. But optimisation and code generation are still done by the C2, right? So I can test now how good MSVC would be able to optimise my code rather than waiting for the bug to be fixed. I.e. this gives me the ability to optimise my code now while I don't have much code yet and can refactor things easily. Tom
kind of works. This cannot be considered a serious toolset though. Why
I've been using C2 clang as my daily Windows compiler for over a year now. Just for the improved warnings and diagnostics alone it is amazing. I know Microsoft say it's not production ready, but I think they more are referring to incompleteness rather than quality of output. It does also ICE quite a bit, but much less than MSVC which Outcome v2 currently murders despite being a very simple C++ library, much less complex than Outcome v1 (bug is submitted to Microsoft, they have confirmed it). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
[Niall Douglas]
I've been using C2 clang as my daily Windows compiler for over a year now. Just for the improved warnings and diagnostics alone it is amazing. I know Microsoft say it's not production ready
Sorry, but we aren't planning to update Clang/C2 for C++. Clang/C2 3.8 in VS 2017 15.3 (first toolset update) will be the final version supported by our STL. We're now testing our STL with Clang/LLVM 4.0 which will be supported in the second toolset update - unless (depending on release timing) I increase the required version to Clang/LLVM 5.0. The Clang/LLVM team has been doing amazing work to ensure source and binary compatibility; by "will be supported" I mean that on Microsoft's end, we're running Clang/LLVM in our test harness (against our own test suites, and libc++'s tests with our STL) to find obscure issues and prevent regressions as we change our code and take advantage of new features. For example, Clang/LLVM 4.0 lacked an atomic builtin; the workaround is to include <intrin.h> before <atomic>. In the second toolset update, I do this automatically as a workaround for 4.0 (and will remove this for 5.0). We've also reported a few bugs upstream, which will improve Clang for everyone. This is much like how Boost supported MSVC for many many years, but now we extensively test it against our development compiler, preventing many bugs from ever appearing. Stephan T. Lavavej Principal Software Engineer, Visual C++ Libraries
Stephan T. Lavavej wrote:
Sorry, but we aren't planning to update Clang/C2 for C++. Clang/C2 3.8 in VS 2017 15.3 (first toolset update) will be the final version supported by our STL. We're now testing our STL with Clang/LLVM 4.0 which will be supported in the second toolset update - unless (depending on release timing) I increase the required version to Clang/LLVM 5.0.
But Clang/C2 is installed by the Visual Studio installer and can be chosen as a toolset from the dropdown; will the update install Clang/LLVM instead?
[Peter Dimov]
But Clang/C2 is installed by the Visual Studio installer and can be chosen as a toolset from the dropdown; will the update install Clang/LLVM instead?
At this time, we aren't planning to add Clang/LLVM to the VS installer. (I should mention that while we're testing Clang/LLVM with our STL and I consider it to be a supported front-end equal to C1XX and EDG, it isn't *officially* supported by Microsoft, and other libraries aren't being tested with it.) STL
Stephan T. Lavavej wrote:
[Peter Dimov]
But Clang/C2 is installed by the Visual Studio installer and can be chosen as a toolset from the dropdown; will the update install Clang/LLVM instead?
At this time, we aren't planning to add Clang/LLVM to the VS installer.
That's a bit odd; you won't be supporting the one that is being installed and will be supporting one that isn't.
On 27 June 2017 at 23:10, Peter Dimov via Boost <boost@lists.boost.org> wrote:
That's a bit odd; you won't be supporting the one that is being installed and will be supporting one that isn't.
I guess the realisation has come that Clang/C2 is just a waste of time. And, yeah, it's odd. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On 27 June 2017 at 15:43, Peter Dimov via Boost <boost@lists.boost.org> wrote:
kind of works. This cannot be considered a serious toolset though. Why not use the LLVM Clang instead?
+1 Clang in the front, but VC in the back, it's a transpiler... degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
degski wrote:
On 27 June 2017 at 15:43, Peter Dimov via Boost <boost@lists.boost.org> wrote:
kind of works. This cannot be considered a serious toolset though. Why not use the LLVM Clang instead?
+1
Clang in the front, but VC in the back, it's a transpiler...
To be fair, I was referring to the Boost.Build support (to the extent there is one) for this toolset, and not to its quality or utility. I also use it from the VS IDE and it's pretty good for double-checking code or compiling something which VC can't. Nevertheless, for those who'd take the advice to use the LLVM one, here's what I have in user-config from last time: using clang : 4.0 : "C:/LLVM-4.0.0-x64/bin/clang.exe" : <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;
On 27/06/2017 12:40, Peter Dimov via Boost wrote:
Tom Westerhout wrote:
On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
This is what I have in my user-config from earlier tests:
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe"
: <linkflags>-v <linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;
Somehow clang decides to prepend target to the linker command:
"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well, obviously, it is not. Do you know how to work around this issue?
No idea. I think that this worked before, an update to VS 2017 probably broke it. I can't find where in Clang's sources is the i686-pc-windows-msvc- prepended and why, and massaging the path doesn't help. -fuse-ld is handled here:
https://clang.llvm.org/doxygen/ToolChain_8cpp_source.html#l00375
Might it have something to do with "address-model=64" being missing from the b2 command invocation perhaps? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 06/27/17 14:40, Peter Dimov via Boost wrote:
Tom Westerhout wrote:
On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
This is what I have in my user-config from earlier tests:
using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe"
: <linkflags>-v <linkflags>"-fuse-ld=\"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25903\\bin\\HostX86\\link.exe\""
;
Somehow clang decides to prepend target to the linker command:
"i686-pc-windows-msvc-C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
gets called in place of
"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX86\\x86\\link.exe"
Clang then complains that the program is not executable. Well, obviously, it is not. Do you know how to work around this issue?
No idea. I think that this worked before, an update to VS 2017 probably broke it.
Looks more like it fixed it. Your version seems newer than what Tom quoted.
On 27/06/2017, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 06/27/17 14:40, Peter Dimov via Boost wrote:
No idea. I think that this worked before, an update to VS 2017 probably broke it.
Looks more like it fixed it. Your version seems newer than what Tom quoted.
Indeed, LLVM's code Peter gave a link to looks right too. On 27/06/2017, Peter Dimov via Boost <boost@lists.boost.org> wrote:
The plain -fuse-ld=link.exe kind of works now (it didn't before.) There are other problems however, exceptions are off for some reason.
OK, no idea why, but this solves the problem. With ClangC2 I need to call vcvarsall anyway (Boost.Build doesn't do it, because it thinks we're on linux), so link.exe is on the PATH. Thanks a lot! By the way, should I maybe submit a feature request to Boost.Build to add a clang-c2.jam? clang.jam currently dispatches between clang-darwin.jam and clang-linux.jam, so it should be easy to add support for clang-c2.jam. I don't yet feel competent enough with BB to implement it myself though. Does anyone else want this functionality? Tom
participants (6)
-
Andrey Semashev -
degski -
Niall Douglas -
Peter Dimov -
Stephan T. Lavavej -
Tom Westerhout