Boost.Build and Microsoft C2 clang

Niall Douglas

27 Jun 2017 27 Jun '17

12:02 a.m.

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/

Show replies by date

Peter Dimov

27 Jun 27 Jun

12:13 a.m.

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\"" ;

Tom Westerhout

8:23 a.m.

On 27/06/2017, Peter Dimov via Boost 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

Peter Dimov

11:40 a.m.

Tom Westerhout wrote:

...

On 27/06/2017, Peter Dimov via Boost 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

Peter Dimov

11:51 a.m.

...

No idea. I think that this worked before, an update to VS 2017 probably broke it.

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.

Peter Dimov

12:43 p.m.

...

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?

Tom Westerhout

1:08 p.m.

On 27/06/2017, Peter Dimov via Boost 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

Niall Douglas

2:12 p.m.

...

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/

Stephan T. Lavavej

5:32 p.m.

[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 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

Peter Dimov

5:36 p.m.

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?

Stephan T. Lavavej

8:07 p.m.

[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

Peter Dimov

8:10 p.m.

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.

degski

28 Jun 28 Jun

3:27 p.m.

On 27 June 2017 at 23:10, Peter Dimov via Boost 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

degski

3:21 p.m.

On 27 June 2017 at 15:43, Peter Dimov via Boost 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

Peter Dimov

4:14 p.m.

degski wrote:

...

On 27 June 2017 at 15:43, Peter Dimov via Boost 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 ;

Niall Douglas

27 Jun 27 Jun

11:52 a.m.

On 27/06/2017 12:40, Peter Dimov via Boost wrote:

...

Tom Westerhout wrote:

...
On 27/06/2017, Peter Dimov via Boost 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/

Andrey Semashev

12:13 p.m.

On 06/27/17 14:40, Peter Dimov via Boost wrote:

...

Tom Westerhout wrote:

...
On 27/06/2017, Peter Dimov via Boost 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.

Tom Westerhout

12:33 p.m.

On 27/06/2017, Andrey Semashev via Boost 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 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

2709

Age (days ago)

2710

Last active (days ago)

List overview

Download

17 comments

6 participants

participants (6)

Andrey Semashev
degski
Niall Douglas
Peter Dimov
Stephan T. Lavavej
Tom Westerhout