Paul A. Bristow wrote:

With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a command line...

I still get

In file included from ..\..\..\boost/config.hpp:44: ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef>

You never mentioned how you got rid of that error. Would not adding the MSVC include directory manually with -isystem work?

But I note that the line above mentions to object file location is

clang-linux-4.0.0\debug\hello_boost.obj

but default target x86_64-pc-windows-msvc

should I expect Clang-msvc here?

I have no idea why we have two clang toolsets, or which would be the correct one to use here.

On 3/25/2017 4:17 AM, Peter Dimov via Boost wrote:

Paul A. Bristow wrote:

...

With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a command line...

...

I still get

In file included from ..\..\..\boost/config.hpp:44: ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef>

You never mentioned how you got rid of that error.

Would not adding the MSVC include directory manually with -isystem work?

...

But I note that the line above mentions to object file location is

clang-linux-4.0.0\debug\hello_boost.obj

but default target x86_64-pc-windows-msvc

should I expect Clang-msvc here?

I have no idea why we have two clang toolsets, or which would be the correct one to use here.

Disclaimer: I contributed clang-win.jam to Boost Build but did not write it and do not know how it works. Nobody else who knows how Boost build works internally has ever taken an interest in it and I am not qualified to fix any of its problems. The two clang toolsets are clang, which normally translates to clang-linux, and clang-win. The former is used on Linux, Mac, and on Windows when targeting mingw(-64)/gcc. Using VC++ as the backend you normally use clang-win. However clang targeting VC++ is broken in Boost PP because the clang developers incorrectly emulated the already non-standard VC++ preprocessor. Whether -fno-ms-compatibility fixes anything or does anything I do not know. I have never been able to find the slightest documentation from clang about it, but then again clang's documentation has always taken a distinct backseat to clang's development ( I am being nice here ). I suspect that even when using -fno-ms-compatibility you still need to use the clang-win toolset since you are still using the VC++ backend. If I knew what -fno-ms-compatibility actually does vis-a-vis predefined macros I would try to update the BoostPP config.hpp accordingly. I was hoping to find out more about it in the VS2017 documentation, but since Microsoft put out VS2017 without any documentation ( nice going Microsoft ! ) that is currently impossible. I explained to Paul via e-mail my rather elaborate setup for testing clang on Windows, both for targeting mingw(-64)/gcc and VC++. It is elaborate since it involves setting the PATH variable without which, AFAIK, clang and its gcc/VC++ backends do not work.

Edward Diener wrote:

There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special VC++ variadics workarounds.

Yes there was, thanks for the hint. #define BOOST_PP_CONFIG_FLAGS() 1 #include #define BOOST_PP_VARIADICS_MSVC 0 #include #include int main() { namespace mpl = boost::mpl; using L = mpl::list<>; using L2 = mpl::push_front; } works. The reason is # elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || !defined __EDG__ || defined(__INTELLISENSE__) || defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) # define BOOST_PP_VARIADICS 1 # undef BOOST_PP_VARIADICS_MSVC # define BOOST_PP_VARIADICS_MSVC 1 which defines BOOST_PP_VARIADICS_MSVC for Clang and must not. You can tell Clang to not define _MSC_VER (-fmsc-version="0"), but MS's headers don't work with that yet (although STL said they are going to.) -fno-ms-compatibility is default for Clang/C2 at least, so I think that the above should just define BOOST_PP_VARIADICS_MSVC to 0 on Clang.

On 3/25/2017 10:46 AM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special VC++ variadics workarounds.

Yes there was, thanks for the hint.

#define BOOST_PP_CONFIG_FLAGS() 1 #include

#define BOOST_PP_VARIADICS_MSVC 0

#include #include

int main() { namespace mpl = boost::mpl;

using L = mpl::list<>; using L2 = mpl::push_front; }

works.

The reason is

# elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || !defined __EDG__ || defined(__INTELLISENSE__) || defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) # define BOOST_PP_VARIADICS 1 # undef BOOST_PP_VARIADICS_MSVC # define BOOST_PP_VARIADICS_MSVC 1

which defines BOOST_PP_VARIADICS_MSVC for Clang and must not.

I am well aware of what is in config.hpp and why.

You can tell Clang to not define _MSC_VER (-fmsc-version="0"), but MS's headers don't work with that yet (although STL said they are going to.)

-fno-ms-compatibility is default for Clang/C2 at least, so I think that the above should just define BOOST_PP_VARIADICS_MSVC to 0 on Clang.

My problem is that I do not know what -fno-ms-compatibility sets as predefined macros. I suppose I can test it and then try to adjust config.hpp accordingly but I hate doing something when there is no documentation and things can change anytime clang, or is it Microsoft with Clang/C2, gets it in their head to change things again. I do not even know what -fno-ms-compatibility does as far as the preprocessor is concerned; does this mean we are back to clang's normal C++ standard preprocessor as in clang for Linux or clang for Windows targeting mingw(-64)/gcc ? I know I am being unreasonably stubborn but I absolutely hate it when clang or a Microsoft refuses to document something and then expects everyone to jump through hoops trying to figure out what they have done and/or react to what they decide to do next. My guess, through some unofficial blogs, is that -fno-ms-compatibility sets __clang__, _MSC_VER, and __GNUC__ to various values. I can test this with various releases of clang and the clang-win toolset, but I have no idea even how to invoke clang/C2 in VS2015/VS2017, since there is no documentation about clang/C2 in the former and there is no documentation for anything in the latter.

On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

My problem is that I do not know what -fno-ms-compatibility sets as predefined macros.

Well given that BOOST_PP_VARIADICS_MSVC=0 works at least some of the time and BOOST_PP_VARIADICS_MSVC=1 never works, it seems to me that the choice is a rather easy one and does not depend on any predefined macros.

I am not sure what you are saying here: 1) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang targeting VC++ allows that compiler to work with BoostPP ? 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang targeting VC++, allows that compiler to work with BoostPP when -fno-ms-compatibility is defined ? 3) 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang targeting VC++, allows clang/C2 to work with BoostPP when -fno-ms-compatibility is defined ? Or are you telling me something else ?

I'm also telling you that since BOOST_PP_VARIADICS_MSVC=1 never works with any Clang, there is perhaps no reason to ever set it to 1 regardless of what Clang it is and what options have been defined.

Unless of course BOOST_PP_VARIADICS_MSVC=1 works on some Clang configurations - you know better than me if that's the case, but I was left with the impression that you consider Clang in -fms-compatibility mode hopelessly broken.

Edward Diener wrote:

Try running all the Boost PP tests <g>. I would be very surprised if they worked in -fno-ms-compatibility mode. I will try it myself with clang targeting VC++ using clang-win.

Even if all the PP tests don't pass, if what MPL needs works, that would at least solve Paul's immediate problem. (And not only his, I suppose.)

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 26 March 2017 00:52 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Edward Diener wrote:

...

Try running all the Boost PP tests <g>. I would be very surprised if they worked in -fno-ms-compatibility mode. I will try it myself with clang targeting VC++ using clang-win.

Even if all the PP tests don't pass, if what MPL needs works, that would at least solve Paul's immediate problem. (And not only his, I suppose.)

My current needs are indeed quite simple (and might be circumnavigated by removing use of float_distance.hpp (thus next.hpp) checking the generation of some simple numerical code. So I'll give that all a try. I remain still confused as to what controls the choice of clang-linux and clang-win, and what needs to switched. Perhaps trying to use some of the features in https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-code... will enlighten me. With the compatibility mode on, and providing an include to the MSVC cstddef, I still get references to clang-linux. So does this mean that I am/should be using mingw cstddef and libstd++ for STL? I'm very grateful for the all thought and work going into this meanwhile. Does all this mean that I would be better off getting the very newest VS update? (A task that I need to do anyway sometime). Thanks Paul

On 3/26/2017 1:38 AM, Paul A. Bristow via Boost wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 26 March 2017 00:52 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Edward Diener wrote:

...

Try running all the Boost PP tests <g>. I would be very surprised if they worked in -fno-ms-compatibility mode. I will try it myself with clang targeting VC++ using clang-win.

Even if all the PP tests don't pass, if what MPL needs works, that would at least solve Paul's immediate problem. (And not only his, I suppose.)

My current needs are indeed quite simple (and might be circumnavigated by removing use of float_distance.hpp (thus next.hpp) checking the generation of some simple numerical code.

So I'll give that all a try.

I remain still confused as to what controls the choice of clang-linux and clang-win, and what needs to switched.

Normal use of the clang toolset means clang-linux on Linux and Windows, and clang-darwin on the Mac.

Perhaps trying to use some of the features in

https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-code...

will enlighten me.

This probably needs the clang-win toolset since the backend is VC++ as I understand it, even with -fno-ms-compatibility. However because the docs are mostly non-existent I really do not know ( or personally care because I would not touch clang targeting VC++ as it is now implemented in the preprocessor ).

With the compatibility mode on, and providing an include to the MSVC cstddef, I still get references to clang-linux. So does this mean that I am/should be using mingw cstddef and libstd++ for STL?

I'm very grateful for the all thought and work going into this meanwhile.

Does all this mean that I would be better off getting the very newest VS update? (A task that I need to do anyway sometime).

Thanks

Paul

On 26 March 2017 at 08:07, Edward Diener via Boost wrote:

This probably needs the clang-win toolset since the backend is VC++ ...

This *surely* needs the clang-win toolset since one is (wants to be) using the Dinkumware (VC++'s) STL. Clang/C2 is using the VC++ backend C2 (the VC++ (cl.exe) frontend is called C1), while Clang/LLVM is using the LLVM backend (LLVM), not any VC++ backend. I'm happy to be corrected, and please do, if my understanding of matters is wrong, in which case I apoligize up front for rambling on about this. degski

On 26 March 2017 at 09:39, Peter Dimov via Boost wrote:

LLVM Clang finds and uses the 14.1 headers for me when using the clang-linux toolset. I could tell because it gave me errors in these headers when I wasn't supplying -fms-version=1910.

It seeems to me that that was not was intended. But having said that, if clang-linux works (with the Dinkumware STL), then progress is definitely being made and we're moving towards having just clang-any (on the 3 major platforms). I (and I guess I'm not alone) really appreciate the work (by yourself and others) that is being put into this!

clang-win is outdated.

Yes, it's lagging, but I would say the only benefit is the better debugging.

Clang under Windows is more or less the same as Clang under Linux now, except that it targets the Microsoft ABI (and fails to link).

Don't know about linking, must be a path problem or something to do with the clang-*linux* bit (ELF?). I'm using Clang/LLVM (from the VS2015 IDE) on a daily basis, no issues.

Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's options natively and uses clang.exe.

Great, cannot wait getting back home from Central-America to Central -Europe, so I can give it a try, as hotel WIFI is flaky here. Are you talking about Clang/C2 or Clang/LLVM?

A proper clang-win toolset today would treat Clang as Clang, not as cl.exe, only it would replace the link phase with a working one.

+1

And a proper clang-c2 toolset would do the same except it would use 14.0/14.1 as the version and look for clang.exe at the appropriate locations.

If Clang/LLVM works as any Clang, the only difference should be the backend. Obviously, one can only hope for this to work with VC14.1(0) or higher... degski

Edward Diener wrote:

Try running all the Boost PP tests <g>. I would be very surprised if they worked in -fno-ms-compatibility mode. I will try it myself with clang targeting VC++ using clang-win.

I tried and failed. Clang/C2 in VS 2017 is in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\clang.exe so I put using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <cxxflags>-fno-ms-compatibility <linkflags>-v ; in user-config.jam. This failed with "can't find c2". I then tried a VS2017 developer command prompt. Clang then compiles, but linking fails with: clang-linux.link ..\..\bin.v2\libs\mp11\test\mp_remove_if.test\clang-linux-14.1\ debug\mp_remove_if.exe clang with Microsoft CodeGen version 3.8.0 Provided as - is without support C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\x86\c2.dll version 19.10.25903.0 Target: i686-pc-windows-msvc Thread model: posix InstalledDir: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86 "link.exe" "-out:..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.exe" -defaultlib:libcmt -nologo -debug --start-group "..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.obj" -Bstatic -Bdynamic --end-group clang.exe: error: unable to execute command: program not executable clang.exe: error: linker command failed with exit code 1 (use -v to see invocation) So, Clang/C2 can't link for some reason. The link rule probably needs to be changed to use link.exe, but that's beyond my capabilities right now.

Ideally if clang targeting VC++ actually emulated the VC++ non-standard preprocessor perfectly BOOST_PP_VARIADICS_MSVC=1 would absolutely have to be defined in order for clang targeting VC++ to work properly with Boost PP.

Bug compatibility with cl.exe has never been a Clang goal. The point of -fms-compatibility was to compile MS's headers. Those however have improved to a point where they work in -fno-ms-compatibility mode, and this is default in 2017 now. So I think that we can ignore -fms-compatibility from now on as there's no need to use it.

Edward Diener wrote:

Sure but that is not right in the long run because you are turning it off for VC++ also.

It's not, I temporarily switched it off just for the test.

Edward Diener wrote:

I have updated Boost PP on the develop branch to support the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.

...failed updating 1 target... ...skipped 2 targets... ...updated 133 targets... The only error is config_info.exe, because my Clang configuration can't link, as explained. My two errors in my previous run were (1) forgetting to patch the first _MSC_VER section to use strict and (2) using <cxxflags> for -fno-ms-compatibility, which left all C tests in -fms-compatibility mode. No idea why it doesn't work for you.

...

Edward Diener wrote:

...

I have updated Boost PP on the develop branch to support the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.

...failed updating 1 target... ...skipped 2 targets... ...updated 133 targets...

For reference, results in -fms-compatibility:

...failed updating 45 targets... ...skipped 46 targets... ...updated 45 targets...

And same, but using the strict config here as well:

...failed updating 2 targets... ...skipped 3 targets... ...updated 131 targets...

LLVM 4.0.0 Clang (using clang-linux toolset), -fno-ms-compatibility: ...failed updating 1 target... ...skipped 3 targets... ...updated 262 targets... The failure is because you pass -std=c++0x, but MS's headers indirectly included by config_info use C++14 features. Should work with -std=c++14. -fms-compatibility (using the strict config, as patched): ...failed updating 1 target... ...skipped 3 targets... ...updated 132 targets... This one doesn't even fail seq.cpp, was probably a bug they fixed. No idea why you couldn't get it to work, all I did was install LLVM in C:\LLVM and then added using clang : 4.0 : "C:/LLVM/bin/clang.exe" : <compileflags>-fno-ms-compatibility ; in user-config.jam. I probably don't even need the <compileflags>, it works either way.

using clang : 4.0 : "C:/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <linkflags>-v ;

And now it fails to link with the usual mysterious ... clang.exe: error: unable to execute command: program not executable clang.exe: error: linker command failed with exit code 1 (use -v to see invocation)

about which problem I can't find anything sensible.

A-ha. using clang : 4.0 : "C:/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ; This whines about ignoring unknown argument: --start-group ignoring unknown argument: -Bstatic ignoring unknown argument: -Bdynamic ignoring unknown argument: --end-group because lld takes MS link.exe command-line options, not GNU ld, but it links.

Edward Diener wrote:

but I strongly believe that my Boost PP config.hpp for -fno-ms-compatibility is correct. I could not follow on your subsequent posts what you are doing so if you can stick to a single reply it would be appreciated.

TL;DR as I said yesterday, you need to to the changes unconditionally for __clang__ and not look at __GNUC__.

Edward Diener wrote: On 3/26/2017 7:59 AM, Peter Dimov via Boost wrote:

...

TL;DR as I said yesterday, you need to to the changes unconditionally for __clang__ and not look at __GNUC__.

I do not understand this. You are saying that __clang__ being defined and _MSC_VER being defined should always be strict compliance with variadics turned on but without any VC++ related fixes ?

Yes. Before the changes: clang -fms-compatibility: broken clang -fno-ms-compatibility: broken After your changes (conditional upon __GNUC__): clang -fms-compatibility: broken clang -fno-ms-compatibility: working After same changes, unconditional: clang -fms-compatibility: working clang -fno-ms-compatibility: working

What about the so-called emulation by clang of the non-standard VC++ preprocessor ?

There apparently exists no such emulation, at least as far as the PP tests show. Maybe it existed once, I don't know, but this doesn't seem to be the case today.

Edward Diener wrote:

How did you get just clang.jam to work ? Doesn't it need VC++ support when using clang-cl ?

I installed LLVM 4.0 in C:\LLVM and put using clang : 4.0 : "C:/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ; in my user-config.jam. It found my VS 2017 installation by itself. There was no need to use the developer command prompt or put anything into PATH.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 26 March 2017 17:11 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Edward Diener wrote:

...

How did you get just clang.jam to work ? Doesn't it need VC++ support when using clang-cl ?

I installed LLVM 4.0 in C:\LLVM and put

using clang : 4.0 : "C:/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;

in my user-config.jam. It found my VS 2017 installation by itself. There was no need to use the developer command prompt or put anything into PATH.

I'm trying to walk before I can run (but have stumbled :-( ) I:\modular-boost\libs\hello_boost\example\jamfile.v2 just calls run hello_boost.cpp ; I have pulled Edward's pre-processor update https://github.com/boostorg/preprocessor/commit/dfc1c46ecedef21274eb142e267e... and tried this in my user_config.jam with discouraging results. It picks up the compiler as expected (I think) notice: will use 'C:/LLVM/bin/clang.exe' for clang-linux, condition <toolset>clang-linux-4.0.0 but doesn't find any targets or do anything beyond config checks??? Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) delete I:\modular-boost\bin.v2\libs\hello_boost to check what is created. But there is no expected folders and files here. But I still only have VS 2015 14.0.25402.00 update 3RC - does this mean I need to update? (Sigh) Or use a different <compileflags>-fmsc-version=1910 ??? Or am I doing something silly? But thanks for making progress on this - I still hope to catch up. Paul PS I would use Cygwin, but I already have mingw installed and changing would muck other things up.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 27 March 2017 16:03 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Paul A. Bristow wrote:

...

I:\modular-boost\libs\hello_boost\example\jamfile.v2 just calls run hello_boost.cpp ;

What are the entire contents of this Jamfile? Where does this hello_boost come from?

jamfile and hello_boost.cpp (a hello World that uses boost/config) attached. As I feared, doing something silly. Now I get something as bad - back to missing the cstddef file. I've tried adding to user_config.jam <cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include" and as many other other variants as I can conceive, but the quoting is not working right and the compiler finds the space and stops rather than finding the file. I think this is a bug in bjam? but I don't see how to get around it. I have added an INCLUDE= C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt but I don't see how to add a second item using the windows environment Variable editor. (Using the Codeblocks IDE - to confuse myself completely, adding this include folder as a Search directory allows some progress, at least finding the MS <cstddef>). Suggestions? And many thanks. Paul PS You didn't say if I really needed the most recent March 2017 VS update? I:\modular-boost\libs\hello_boost\example>b2 Performing configuration checks - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) ...found 200 targets... ...updating 13 targets... common.mkdir ..\..\..\bin.v2\libs\hello_boost common.mkdir ..\..\..\bin.v2\libs\hello_boost\example common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0 common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static compile-c-c++ ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello _boost.obj hello_boost.cpp msvc.link ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello _boost.exe msvc.manifest ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello _boost.exe testing.capture-output ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello _boost.run 1 file(s) copied. **passed** ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello _boost.test ...updated 13 targets... I:\modular-boost\libs\hello_boost\example>b2 toolset=gcc-6.3.0 Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - symlinks supported : yes ...found 192 targets... ...updating 6 targets... common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0 common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug gcc.compile.c++ ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.o gcc.link ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.exe testing.capture-output ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.run 1 file(s) copied. **passed** ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.test ...updated 6 targets... I:\modular-boost\libs\hello_boost\example>b2 toolset=clang-4.0.0 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) ...found 196 targets... ...updating 6 targets... common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0 common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file "I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\ \debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility -fms-compatibility-version=19.0.24123 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc #include "..." search starts here: #include <...> search starts here: ..\..\.. C:\LLVM\bin\..\lib\clang\4.0.0\include C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt End of search list. In file included from hello_boost.cpp:13: In file included from ..\..\..\boost/config.hpp:44: ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef> ^~~~~~~~~ 1 error generated. "C:/LLVM/bin/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -v -m64 -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o "..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj" "hello_boost.cpp" ...failed clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj... ...skipped hello_boost.exe for lack of hello_boost.obj... ...skipped hello_boost.run for lack of hello_boost.exe... ...failed updating 1 target... ...skipped 3 targets... ...updated 2 targets...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 27 March 2017 18:12 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Paul A. Bristow wrote: The correct way to set the include path is with

<include>"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

Adding that to my clang compiler options in my user-config.jam has no effect (wrong place?). But adding that to my hello_boost jamfile produces a command line "C:/LLVM/bin/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -v -fmsc-version=1900 -m64 -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -o "..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj" "hello_boost.cpp" which is as I expect - apart from the clang-linux rather than clang-msvc or clang-win? It start as I expect too clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.0 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file "I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\ \debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -I "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\include" -internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility -fms-compatibility-version=19.0 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc #include "..." search starts here: #include <...> search starts here: ..\..\.. C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include C:\LLVM\bin\..\lib\clang\4.0.0\include C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt but then there are warnings, and then terminates with extreme prejudice :-( In file included from hello_boost.cpp:13: In file included from ..\..\..\boost/config.hpp:48: In file included from ..\..\..\boost/config/stdlib/dinkumware.hpp:98: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\typeinfo:21: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception:320:8: warning: private field '_Data1' is not used [-Wunused-private-field] void* _Data1; ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception:321:8: warning: private field '_Data2' is not used [-Wunused-private-field] void* _Data2; ^ Assertion failed: ~FI && "Expected valid index", file D:\src\llvm_package_4.0.0\llvm\lib\CodeGen\AsmPrinter/DwarfDebug.h, line 92 Wrote crash dump file "C:\Users\Paul\AppData\Local\Temp\clang.exe-ad54f0.dmp" ... So, in some desperation, I changed my system variable INCLUDE to provide the necessary MSVC include files, and could then use bjam to build the chrono and system libraries with Clang (lots of warnings, some not suppressible) , and run my timing test to compare Lambert_w timing with GCC and MSVC (surprisingly Clang and MSVC are similar but GCC takes over twice as long). Phew! But thanks for all your many efforts on my behalf. I think that the changed to MPL config were critically important). Paul PS I think the next step is to install the VS 2017 upgrade and hope this include problem just goes away. PPS (Changing the system INCLUDE might not be a good idea? Does anyone know how this works usually? C:\Users\Paul\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd contains this setting SET INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\winrt;C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt) so how is Clang not finding/using it??? --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 27 March 2017 18:24 To: boost Cc: degski Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

On 27 March 2017 at 10:59, Paul A. Bristow via Boost wrote:

...

<cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

<cxxflags> -I"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

I've tried this, and a host of other possibles. What is *your* bjam version? C:\Users\Paul>b2 -v Boost.Jam Version 2015.07. OS=NT. Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc. Copyright 2001 David Turner. Copyright 2001-2004 David Abrahams. Copyright 2002-2015 Rene Rivera. Copyright 2003-2015 Vladimir Prus. My bjam/b2 is recent from the develop branch. Baffling :-( Thanks Paul

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 27 March 2017 17:25 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

On 3/27/2017 9:57 AM, Paul A. Bristow via Boost wrote:

...

But I still only have VS 2015 14.0.25402.00 update 3RC - does this mean I need to update? (Sigh)

Or use a different <compileflags>-fmsc-version=1910 ???

I use -fmsc-version=1900 for VS2015. My entry using the distributed clang 4.0 version, which by default targets VC++, is:

using clang : 4.0 : C:/Utilities/LLVM/400/x32/bin/clang++ : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1900 <linkflags>-fuse-ld=lld ;

and is invoked with "toolset=clang-4.0".

For me, this gives the same missing cstddef. clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.0 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file "I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\ \debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility -fms-compatibility-version=19.0 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc #include "..." search starts here: #include <...> search starts here: ..\..\.. C:\LLVM\bin\..\lib\clang\4.0.0\include C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt End of search list. In file included from hello_boost.cpp:13: In file included from ..\..\..\boost/config.hpp:44: ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef> ^~~~~~~~~ 1 error generated. There is something I am doing different/wrong here? (Before I can even try to get into Meta-troubles ;-) ) Paul