The clang-win toolset is known to be broken. I don't know if it ever worked. I believe that clang-linux (using regular clang, not clang-cl) works for most platforms other than OSX. (Yes, I know, cleaning up this mess is on my todo list.)

Using: using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" : <compatibility>vc14.1 ; Results in: $ ../../../b2 config_info clang C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in argument <cxxflags>-std:c++latest ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in argument <define>$(flag)=1 M:/data/boost/boost/tools/build/src/build\configure.jam:288: in try-find-build *** argument error * rule log-check-result ( result ) * called with: (  ) * missing argument result M:/data/boost/boost/tools/build/src/build\configure.jam:86:see definition of rule 'log-check-result' being called M:/data/boost/boost/tools/build/src/build\configure.jam:391: in find-builds-raw M:/data/boost/boost/tools/build/src/build\configure.jam:450: in configure.find-builds M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in modules.call-in M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call M:/data/boost/boost/tools/build/src/build\property.jam:144: in property.evaluate-conditionals-in-context M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in evaluate-requirements M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in common-properties2 M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in targets.common-properties M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in class@basic-target.generate M:/data/boost/boost/tools/build/src/build\targets.jam:812: in generate-really M:/data/boost/boost/tools/build/src/build\targets.jam:784: in class@main-target.generate M:/data/boost/boost/tools/build/src\build-system.jam:797: in load M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build M:\data\boost\boost\boost-build.jam:17: in module scope Using: using clang : : "C:/Program Files/LLVM/bin/clang.exe" ; Does indeed seem to work OK, and as far as I can tell it's clang on top of msvc-14.1.

They're harmless for now, but will break at some unspecified time in the future, when I switch to the new lexer.

It would help a lot if the message said which characters were special and need escaping. Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

On 3/9/2018 3:02 PM, John Maddock via Boost wrote:

...

   The clang-win toolset is known to be broken.  I don't know if it ever worked.  I believe that clang-linux (using regular clang, not clang-cl) works for most platforms other than OSX.  (Yes, I know, cleaning up this mess is on my todo list.)

Using:

using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" : <compatibility>vc14.1 ;

My use of clang-cl with clang-5.0 for x32 compilation looks like: using clang : 5.0cl : C:/Utilities/LLVM/500/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 ; It works for me pretty well when invoked as toolset=clang-5.0cl on the b2 command line. Before invoking b2 I am also doing: call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 in order to setup vc++. For x64 compilation it looks like: using clang : 5.0x64cl : C:/Utilities/LLVM/500/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 ; invoked on the b2 command line as toolset=clang-5.0x64cl. Before invoking b2 I am also doing: call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 in order to setup vc++. Needless to say I have other using statements for clang with gcc for various C++ standard levels in the same user-config.jam. I am pretty sure to use the same type of setup with the recently released 6.0 on Windows. Maybe these will help you.

Results in:

$ ../../../b2 config_info clang C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in argument <cxxflags>-std:c++latest ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in argument <define>$(flag)=1 M:/data/boost/boost/tools/build/src/build\configure.jam:288: in try-find-build *** argument error * rule log-check-result ( result ) * called with: (  ) * missing argument result M:/data/boost/boost/tools/build/src/build\configure.jam:86:see definition of rule 'log-check-result' being called M:/data/boost/boost/tools/build/src/build\configure.jam:391: in find-builds-raw M:/data/boost/boost/tools/build/src/build\configure.jam:450: in configure.find-builds M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in modules.call-in M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call M:/data/boost/boost/tools/build/src/build\property.jam:144: in property.evaluate-conditionals-in-context M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in evaluate-requirements M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in common-properties2 M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in targets.common-properties M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in class@basic-target.generate M:/data/boost/boost/tools/build/src/build\targets.jam:812: in generate-really M:/data/boost/boost/tools/build/src/build\targets.jam:784: in class@main-target.generate M:/data/boost/boost/tools/build/src\build-system.jam:797: in load M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build M:\data\boost\boost\boost-build.jam:17: in module scope

Using:

using clang : : "C:/Program Files/LLVM/bin/clang.exe" ;

Does indeed seem to work OK, and as far as I can tell it's clang on top of msvc-14.1.

...

   They're harmless for now, but will break at some unspecified time in the future, when I switch to the new lexer.

It would help a lot if the message said which characters were special and need escaping.

Thanks, John.

On 3/10/2018 3:38 AM, John Maddock via Boost wrote:

...

My use of clang-cl with clang-5.0 for x32 compilation looks like:

using clang : 5.0cl : C:/Utilities/LLVM/500/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  ;

It works for me pretty well when invoked as toolset=clang-5.0cl on the b2 command line. Before invoking b2 I am also doing:

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

in order to setup vc++.

For x64 compilation it looks like:

using clang : 5.0x64cl : C:/Utilities/LLVM/500/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  ;

Thanks for that, I have things semi-working with:

using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" :  <cxxflags>-fmacro-backtrace-limit=0  <cxxstd>17  <cxxflags>-Wno-invalid-token-paste  <compileflags>-fmsc-version=1900  <compileflags>--target=x86_64-pc-windows-msvc  <linkflags>--target=x86_64-pc-windows-msvc  <linkflags>-lmsvcrt  <linkflags>-lkernel32  <linkflags>-luser32    ;

But:

* I can't build dll's, so I need link=static on the command line. * The cxxstd invocation in user-config.jam doesn't work - and clang.jam appends -std=c++11 to the clang command line which breaks several MS headers.  Adding cxxstd=17 to the b2 command line fixes that, but it's a pain. * I'm still getting linker errors I haven't been able to resolve for system calls even with the references to Kernal32 and User32 as above.

I really think we should be using clang-cl, as I suspect it would solve most of this stuff...

clang targeting msvc is the same thing as clang-cl AFAIK. I have never used 'cxxstd' with clang, although when targeting gcc using, for example, '<cxxflags>-std=c++11', works fine for me. For what libraries are you failing to build DLLs ? For what libraries are tou getting linker errors involving kernel32 and user32 ?

Best, John.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 10 March 2018 13:39 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] Clang on Windows

On 3/10/2018 3:38 AM, John Maddock via Boost wrote:

...

...

My use of clang-cl with clang-5.0 for x32 compilation looks like:

using clang : 5.0cl : C:/Utilities/LLVM/500/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 ;

It works for me pretty well when invoked as toolset=clang-5.0cl on the b2 command line. Before invoking b2 I am also doing:

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

in order to setup vc++.

For x64 compilation it looks like:

using clang : 5.0x64cl : C:/Utilities/LLVM/500/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 ;

Thanks for that, I have things semi-working with:

using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" : <cxxflags>-fmacro-backtrace-limit=0 <cxxstd>17 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1900 <compileflags>--target=x86_64-pc-windows-msvc <linkflags>--target=x86_64-pc-windows-msvc <linkflags>-lmsvcrt <linkflags>-lkernel32 <linkflags>-luser32 ;

But:

* I can't build dll's, so I need link=static on the command line. * The cxxstd invocation in user-config.jam doesn't work - and clang.jam appends -std=c++11 to the clang command line which breaks several MS headers. Adding cxxstd=17 to the b2 command line fixes that, but it's a pain. * I'm still getting linker errors I haven't been able to resolve for system calls even with the references to Kernal32 and User32 as above.

I really think we should be using clang-cl, as I suspect it would solve most of this stuff...

I have also been investigating (fumbling with) this can of worms. (Lots of details attached) I have got some things to work, but linking libraries produces an inexplicable (to me) link failure when trying to use Boost.Test and Clang. I have tried this on Codeblocks when I can link to Chrono library OK, but when I try to use Boost.Test using the same test.cpp that passes using GCC7.1.0, I get a final failure LINK : fatal error LNK1561: entry point must be defined There is not a int main() but Boost.Test's own entry function int unit_test_main( init_unit_test_func init_func, int argc, char* argv[] ); that I presume should be fed in place of int main() Is this a Boost.Test config problem that makes Clang and GCC different , or am I doing something silly. Suggestions welcome. Paul msvcrt.lib

On 15 March 2018 at 13:30, Marcel Raad via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Paul A. Bristow via Boost Sent: Donnerstag, 15. März 2018 19:05 To: boost@lists.boost.org Cc: Paul A. Bristow Subject: Re: [boost] Clang on Windows

I have got some things to work, but linking libraries produces an inexplicable (to me) link failure when trying to use Boost.Test and Clang.

I have tried this on Codeblocks when I can link to Chrono library OK, but when I try to use Boost.Test using the same test.cpp that passes using GCC7.1.0, I get a final failure

LINK : fatal error LNK1561: entry point must be defined

There is not a int main() but Boost.Test's own entry function

int unit_test_main( init_unit_test_func init_func, int argc, char* argv[] );

that I presume should be fed in place of int main()

Is this a Boost.Test config problem that makes Clang and GCC different , or am I doing something silly.

I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the MSVC linker.

If you'd do that, you'll have an issue, but... I've just tested building an app not passing /SUBSYSTEM:CONSOLE. It builds and runs, but of course there's no console window (something flashes up, no error or problem). I think the -flto=thin flag is possibly not properly passed around, or the vc linker (link.exe) is invoked instead of lld.exe. As OP's libs are lto instrumented, they can only be linked with lld and the flag -flto=thin. degski

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 16 March 2018 11:20 To: boost Cc: degski Subject: Re: [boost] Clang on Windows

On 15 March 2018 at 13:30, Marcel Raad via Boost wrote:

...

...

-----Original Message----- From: Boost On Behalf Of Paul A. Bristow via Boost Sent: Donnerstag, 15. März 2018 19:05 To: boost@lists.boost.org Cc: Paul A. Bristow Subject: Re: [boost] Clang on Windows

I have got some things to work, but linking libraries produces an inexplicable (to me) link failure when trying to use Boost.Test and Clang.

I have tried this on Codeblocks when I can link to Chrono library OK, but when I try to use Boost.Test using the same test.cpp that passes using GCC7.1.0, I get a final failure

LINK : fatal error LNK1561: entry point must be defined

There is not a int main() but Boost.Test's own entry function

int unit_test_main( init_unit_test_func init_func, int argc, char* argv[] );

that I presume should be fed in place of int main()

Is this a Boost.Test config problem that makes Clang and GCC different , or am I doing something silly.

I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the MSVC linker.

If you'd do that, you'll have an issue, but... I've just tested building an app not passing /SUBSYSTEM:CONSOLE. It builds and runs, but of course there's no console window (something flashes up, no error or problem).

I see this error on Codeblocks IDE which runs the .exe via a console, but also when built using bjam/b2. So I'm not sure if this is relevant?

I think the -flto=thin flag is possibly not properly passed around, or the vc linker (link.exe) is invoked instead of lld.exe.

I'll look into this. I note that John Maddock has <linkflags>-lmsvcrt Should I have x86_64-pc-windows-mgwin rather than x86_64-pc-windows-msvc?

As OP's libs are lto instrumented, they can only be linked with lld and the flag -flto=thin.

This is a useful info. I was unclear if/which linker should be used. (I hoped that either were useable - always the optimist!) Thanks Paul

On 10/03/2018 08:40, John Maddock wrote:

Plus I still see:

In file included from C:\Program Files\LLVM\lib\clang\6.0.0\include\vadefs.h:32: M:\Compilers\VC2017\VC\Tools\MSVC\14.13.26128\include\vadefs.h:112:10: error: expected unqualified-id     void __cdecl __va_start(va_list* , ...);

vadefs.h gets pulled in by limits.h BTW so this is hardly obscure stuff....

All this seems to be fixed by using clang-cl rather than clang.... John. --- This email has been checked for viruses by AVG. http://www.avg.com

On 3/10/2018 6:06 AM, degski via Boost wrote:

Some time ago, got things working quite well with the following project file:

import option ;

using clang : 6.0 : "C:/Program Files/LLVM/bin/clang++.exe" : <compileflags>-fmsc-version=1911

<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.16299.0/x64/rc.exe"

<linkflags>-fuse-ld=lld <linkflags>-flto=thin

<cxxflags>-Wno-gnu-string-literal-operator-template <cxxflags>-Xclang <cxxflags>-flto-visibility-public-std

<cxxflags>-fno-ms-compatibility <cxxflags>-fno-delayed-template-parsing <cxxflags>-Wno-dynamic-exception-spec # TODO: file bug to MS <cxxflags>-Wno-c++11-narrowing # TODO: wut <cxxflags>-D_WINSOCK_DEPRECATED_NO_WARNINGS # TODO: wut

<cxxflags>-std=c++17 <cxxflags>-Wunused-command-line-argument

<cxxflags>-DBOOST_USE_WINDOWS_H <cxxflags>-DBOOST_NO_ANSI_APIS

<cxxflags>-DBOOST_USE_WINAPI_VERSION=0x1000 <cxxflags>-DBOOST_USE_WINDOWS_H=1 <cxxflags>-D_WIN32_WINNT=0x1000

<cxxflags>-D_MT <cxxflags>-D_WIN32 <cxxflags>-D_WIN64 <cxxflags>-DNOMINMAX <cxxflags>-DWIN32_LEAN_AND_MEAN <cxxflags>-D_HAS_AUTO_PTR_ETC=1 <cxxflags>-D_ITERATOR_DEBUG_LEVEL=0 <cxxflags>-D_CRT_DECLARE_NONSTDC_NAMES=1 # clang defines __STDC__, cl does not (see definition of _CRT_INTERNAL_NONSTDC_NAMES)

# <cxxflags>-IC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/include # <linkflags>-LC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/lib/x64 ;

option.set keep-going : false ;

With all of the configuration items, does Clang successfully build C++ MFC Windows Forms and/or DLL projects? --Robert

degski

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost