Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
I am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0 I am using the CodeBlocks IDE (though I don't think that is relevant). The code indirectly uses next.hpp and prior.hpp There are several warnings like this (after adding the -Wignored-attributes option) C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\immintrin.h|45|warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes] I:\modular-boost\boost\mpl\next_prior.hpp|44|error: too many arguments provided to function-like macro invocation| Following suggestions in this thread, I have added -Wno-invalid-token-paste http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.ht... and also -DBOOST_PP_CONFIG_FLAGS=1, but I get a blizzard of errors - see below It would seem that this may be because of a misconfiguration in Boost mpl? If I understand right, the thread above suggests that this is MS pre-processor-specific MPL code because of code in boost/preprocessor/config/config.hpp that determines the MPL code? Is this correct? Target: x86_64-pc-windows-msvc -triple x86_64-pc-windows-msvc19.0.24123 Complete log attached in case this helps. Can anyone say what I am doing wrong and/or suggest a workaround for this? Thanks Paul Compile line is clang++.exe -Wall -fexceptions -Wignored_attributes -D"BOOST_PP_CONFIG_FLAGS()"=1 -m64 -v -Wignored-attributes -Wno-invalid-token-paste -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -c J:\Cpp\Misc\lambert_w_single\lambert_w_single.cpp -o .objs\Misc\lambert_w_single\lambert_w_single.o 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 In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/preprocessor/facilities/expand.hpp:26:10: note: macro 'BOOST_PP_EXPAND_I' defined here # define BOOST_PP_EXPAND_I(x) x ^ In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:1: error: expected a qualified name after 'typename' BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:64:11: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_PARAMS(i, typename T) \ ^ I:\modular-boost\boost/mpl/aux_/preprocessor/params.hpp:58:11: note: expanded from macro 'BOOST_MPL_PP_PARAMS' , BOOST_MPL_PP_AUX_PARAM_FUNC \ ^ ... I:\modular-boost\boost/mpl/void.hpp:71:1: error: expected ',' or '>' in template-parameter-list I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:65:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:38:37: note: expanded from macro 'BOOST_PP_REPEAT_1' # define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d) ^ I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:43:39: note: expanded from macro 'BOOST_PP_REPEAT_1_I' # define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d) ^ <scratch space>:64:1: note: expanded from here BOOST_PP_REPEAT_1_BOOST_PP_REM ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow wrote:
I am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0 ... Following suggestions in this thread, I have added -Wno-invalid-token-paste http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.ht...
You could try disabling Clang's MS mode with -fno-ms-compatibility and see if that helps.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 24 March 2017 18:37 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 am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0 ... Following suggestions in this thread, I have added -Wno-invalid-token-paste http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.ht...
You could try disabling Clang's MS mode with -fno-ms-compatibility and see if that helps.
With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a command line modular-boost\libs\hello_boost\example>b2 toolset=clang-4.0.0 -a -d2 --debug-configuration > clang40_25Mar17.log "c:\LLVM\bin\clang++.exe" -c -x c++ -v -fno-ms-compatibility -O0 -g -fno-inline -Wall -g -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" 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> 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? Do I do this using a different 'triple' and/or target and if so what? compileflags>"-target x86_64-pc-windows-gnu" or ? Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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 25 March 2017 at 05:17, Peter Dimov via Boost <boost@lists.boost.org> wrote:
I have no idea why we have two clang toolsets, or which would be the correct one to use here.
Because there ARE (at least) two, the Clang-msvc option is (for the moment) a dead end, though. @Paul: Edward and Niall have looked into this extensively (there's a few threads on this on the mailing list, around April 2016) and nothing (obvious) seems to work (even after getting the build to start) as a mix of 'errors' in Clang-cl's VC-PP emulation goes together with mis-identification of the Clang/LLVM/C2/VC-STL combo in the boost-headers (possibly clang-cl is the culprit, what -fno-ms-compatibility tries to solve, but it doesn't) starting with type-traits and typeof (but not limited to), which then avalache through the rest of the boost-code. On the bright side, if it doesn't work, there's no need for testing either :-) . Both Niall and Edward have submitted several PR's to Clang, which seem to be ignored. Edward seems to think it's just to big a mess to fix for the Clang team. Without some fixes to type-traits and typeof, one cannot use clang-cl successfully for code that contains boost library headers, even when linking to boost libraries compiled with vanilla VC. It might be that either Niall or Edward has made progress on this subject, but I'm not aware of that. degski
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.
On 25 March 2017 at 08:39, Edward Diener via Boost <boost@lists.boost.org> wrote:
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.
Isn't the issue mostly related to the use of the Dinkumware STL, as opposed to the Clang backends, of which there are two: LLVM (the one Paul was trying to get to work) and C2. The latter gives better debugging support, the former often (not always though) generates better code. degski
Paul A. Bristow wrote:
In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation BOOST_MPL_AUX_NA_SPEC(1, next) ^
I tried to compile #include <boost/mpl/list.hpp> #include <boost/mpl/push_front.hpp> int main() { namespace mpl = boost::mpl; using L = mpl::list<>; using L2 = mpl::push_front<L, void>; } with the build-in Clang/C2, hit 1>../boost-git/boost\boost/mpl/next_prior.hpp(44,1): error : pasting formed 'BOOST_PP_TUPLE_ELEM_O_3(', an invalid preprocessing token [-Winvalid-token-paste] 1>BOOST_MPL_AUX_NA_SPEC(1, next) Tried #define BOOST_PP_CONFIG_FLAGS() 1 at the top, same. The "strict" PP configuration is used, it just doesn't work for some reason I couldn't figure out. It's possible that -fms-extensions also changes the preprocessor and this breaks PP, but without it, MS's headers don't compile. If you tell MPL to not use PP though: #include <boost/mpl/aux_/config/preprocessor.hpp> #undef BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES this simple example works. I've no idea whether more complex ones will. But if you don't insist on an MS-compatible Clang and can stomach the old and busted 3.9, you can just use the Cygwin Clang. That's what I do.
On 3/25/2017 8:30 AM, Peter Dimov via Boost wrote:
Paul A. Bristow wrote:
In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation BOOST_MPL_AUX_NA_SPEC(1, next) ^
I tried to compile
#include <boost/mpl/list.hpp> #include <boost/mpl/push_front.hpp>
int main() { namespace mpl = boost::mpl;
using L = mpl::list<>; using L2 = mpl::push_front<L, void>; }
with the build-in Clang/C2, hit
1>../boost-git/boost\boost/mpl/next_prior.hpp(44,1): error : pasting formed 'BOOST_PP_TUPLE_ELEM_O_3(', an invalid preprocessing token [-Winvalid-token-paste] 1>BOOST_MPL_AUX_NA_SPEC(1, next)
Tried
#define BOOST_PP_CONFIG_FLAGS() 1
at the top, same. The "strict" PP configuration is used, it just doesn't work for some reason I couldn't figure out. It's possible that -fms-extensions also changes the preprocessor and this breaks PP, but without it, MS's headers don't compile.
There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special VC++ variadics workarounds.
If you tell MPL to not use PP though:
#include <boost/mpl/aux_/config/preprocessor.hpp> #undef BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES
this simple example works. I've no idea whether more complex ones will.
But if you don't insist on an MS-compatible Clang and can stomach the old and busted 3.9, you can just use the Cygwin Clang. That's what I do.
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 <boost/preprocessor/config/config.hpp> #define BOOST_PP_VARIADICS_MSVC 0 #include <boost/mpl/list.hpp> #include <boost/mpl/push_front.hpp> int main() { namespace mpl = boost::mpl; using L = mpl::list<>; using L2 = mpl::push_front<L, void>; } 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.
#define BOOST_PP_CONFIG_FLAGS() 1 #include <boost/preprocessor/config/config.hpp>
#define BOOST_PP_VARIADICS_MSVC 0
#include <boost/mpl/list.hpp> #include <boost/mpl/push_front.hpp>
int main() { namespace mpl = boost::mpl;
using L = mpl::list<>; using L2 = mpl::push_front<L, void>; }
works.
It works without #define BOOST_PP_CONFIG_FLAGS() 1 as well. #include <boost/preprocessor/config/config.hpp> #define BOOST_PP_VARIADICS_MSVC 0 is all that's required.
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 <boost/preprocessor/config/config.hpp>
#define BOOST_PP_VARIADICS_MSVC 0
#include <boost/mpl/list.hpp> #include <boost/mpl/push_front.hpp>
int main() { namespace mpl = boost::mpl;
using L = mpl::list<>; using L2 = mpl::push_front<L, void>; }
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.
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.
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 ?
Edward Diener wrote: On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:
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 ?
I'm telling you 3)2), yes, at least for this simple MPL program I tested. If I could get b2 to work with Clang/C2, I would have run the tests, but I'm not sure I can do that. 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.
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.
On 3/25/2017 4:37 PM, Peter Dimov via Boost wrote:
Edward Diener wrote: On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:
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 ?
I'm telling you 3)2), yes, at least for this simple MPL program I tested.
I meant to write "3)" and not "3)2)" above. Sorry ! 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.
If I could get b2 to work with Clang/C2, I would have run the tests, but I'm not sure I can do that.
Touche ! I am not sure whether to use clang ( clang-linux ) or clang-win, but I am guessing the latter is the right match. Also I still don't know how to invoke clang/C2. I will look in the VS2015/VS2017 directory structure unless you know what it is called and where it is ?
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.
Well I can change config.hpp to reflect that. 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. That is the obvious reason why it has been used in that situation.
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.)
Some description (defined macros, defines identifying the toolset, and installation) can be found here <https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/> . degski
-----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
Paul A. Bristow wrote:
I remain still confused as to what controls the choice of clang-linux and clang-win, and what needs to switched.
If you just need to test things using "b2 test toolset=clang", I repeat my recommendation of using Cygwin. It has g++ 6.3 and clang 3.9, and they work more or less "out of the box". The only thing I did was symlink clang-3.9.exe to clang++.exe.
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 <boost@lists.boost.org> 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
degski wrote:
This *surely* needs the clang-win toolset since one is (wants to be) using the Dinkumware (VC++'s) STL.
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. clang-win is outdated. It's predicated on the assumption that the Windows Clang would be a separate animal, a drop-in replacement for Microsoft's cl.exe. This was the original plan, but it has been abandoned for at least a year now, if not more. 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). Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's options natively and uses clang.exe. 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. 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.
On 26 March 2017 at 09:39, Peter Dimov via Boost <boost@lists.boost.org> 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
Just noticed the following, compiling: #if __cplusplus >= 201103L #error This library uses a C++11 compliant compiler #else #error This library will benefit from a C++11 compliant compiler #endif Compiling this with VC14, update 3, (options, a.o.) /std:c++latest, the second line is generated as an error. Compiling this with Clang/LLVM (option a.o.) -std=c++1y results in the first error being produced. It is this bug https://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-o... A value of predefined macro __cplusplus is still 199711L - by Barfy Status : Closed as Deferred Maybe relevant in the context of this thread? 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.
So, Clang/C2 can't link for some reason.
It occurred to me that the PP tests don't need to link. So, ...failed updating 25 targets... ...skipped 26 targets... ...updated 118 targets... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\array.test\clang-linux-14.1\debug\array.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\list.test\clang-linux-14.1\debug\list.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\arithmetic_nvm.test\clang-linux-14.1\debug\arithmetic_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\array_nvm.test\clang-linux-14.1\debug\array_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\comparison_nvm.test\clang-linux-14.1\debug\comparison_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\control_nvm.test\clang-linux-14.1\debug\control_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\iteration_nvm.test\clang-linux-14.1\debug\iteration_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\list_nvm.test\clang-linux-14.1\debug\list_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\repetition_nvm.test\clang-linux-14.1\debug\repetition_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\selection_nvm.test\clang-linux-14.1\debug\selection_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\seq_nvm.test\clang-linux-14.1\debug\seq_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\tuple_nvm.test\clang-linux-14.1\debug\tuple_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\array_c.test\clang-linux-14.1\debug\array_c.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\list_c.test\clang-linux-14.1\debug\list_c.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\arithmetic_c_nvm.test\clang-linux-14.1\debug\arithmetic_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\array_c_nvm.test\clang-linux-14.1\debug\array_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\comparison_c_nvm.test\clang-linux-14.1\debug\comparison_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\control_c_nvm.test\clang-linux-14.1\debug\control_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\list_c_nvm.test\clang-linux-14.1\debug\list_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\selection_c_nvm.test\clang-linux-14.1\debug\selection_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\seq_c_nvm.test\clang-linux-14.1\debug\seq_c_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\tuple_c_nvm.test\clang-linux-14.1\debug\tuple_c_nvm.obj... ...failed clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\isempty_nvm.test\clang-linux-14.1\debug\isempty_nvm.obj... ...failed clang-linux.compile.c.without-pth ..\..\bin.v2\libs\preprocessor\test\isempty_c_nvm.test\clang-linux-14.1\debug\isempty_c_nvm.obj... clang.exe: error: linker command failed with exit code 1 (use -v to see invocation) ...failed clang-linux.link ..\..\bin.v2\libs\preprocessor\test\config_info.test\clang-linux-14.1\debug\config_info.exe... All the _nvm failures are an invalid token paste, which shouldn't in principle happen in a strict configuration, and are probably not something users will encounter because they disable BOOST_PP_VARIADICS by hand. Full failure log attached.
So, Clang/C2 can't link for some reason.
It occurred to me that the PP tests don't need to link. So,
...failed updating 25 targets... ...skipped 26 targets... ...updated 118 targets...
This is with C:\Projects\boost-git\boost\libs\preprocessor>git diff diff --git a/include/boost/preprocessor/config/config.hpp b/include/boost/prepro index 4801903..10778d8 100644 --- a/include/boost/preprocessor/config/config.hpp +++ b/include/boost/preprocessor/config/config.hpp @@ -79,7 +79,7 @@ # elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || !defin # define BOOST_PP_VARIADICS 1 # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && def # define BOOST_PP_VARIADICS 1 @@ -94,7 +94,7 @@ # define BOOST_PP_VARIADICS 1 # if defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || defined( # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # endif # else # undef BOOST_PP_VARIADICS
On 3/25/2017 6:48 PM, Peter Dimov via Boost wrote:
So, Clang/C2 can't link for some reason.
It occurred to me that the PP tests don't need to link. So,
...failed updating 25 targets... ...skipped 26 targets... ...updated 118 targets...
This is with
C:\Projects\boost-git\boost\libs\preprocessor>git diff diff --git a/include/boost/preprocessor/config/config.hpp b/include/boost/prepro index 4801903..10778d8 100644 --- a/include/boost/preprocessor/config/config.hpp +++ b/include/boost/preprocessor/config/config.hpp @@ -79,7 +79,7 @@ # elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || !defin # define BOOST_PP_VARIADICS 1 # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && def # define BOOST_PP_VARIADICS 1 @@ -94,7 +94,7 @@ # define BOOST_PP_VARIADICS 1 # if defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || defined( # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # endif # else # undef BOOST_PP_VARIADICS
Sure but that is not right in the long run because you are turning it off for VC++ also.
On 3/25/2017 6:48 PM, Peter Dimov via Boost wrote:
So, Clang/C2 can't link for some reason.
It occurred to me that the PP tests don't need to link. So,
...failed updating 25 targets... ...skipped 26 targets... ...updated 118 targets...
This is with
C:\Projects\boost-git\boost\libs\preprocessor>git diff diff --git a/include/boost/preprocessor/config/config.hpp b/include/boost/prepro index 4801903..10778d8 100644 --- a/include/boost/preprocessor/config/config.hpp +++ b/include/boost/preprocessor/config/config.hpp @@ -79,7 +79,7 @@ # elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || !defin # define BOOST_PP_VARIADICS 1 # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && def # define BOOST_PP_VARIADICS 1 @@ -94,7 +94,7 @@ # define BOOST_PP_VARIADICS 1 # if defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) || defined( # undef BOOST_PP_VARIADICS_MSVC -# define BOOST_PP_VARIADICS_MSVC 1 +# define BOOST_PP_VARIADICS_MSVC 0 # endif # else # undef BOOST_PP_VARIADICS
I have updated Boost PP on the develop branch to support the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2. I still get plenty of errors with clang 4.0 using clang-win and -fno-ms-compatibility when running the Boost PP tests, but maybe it is good enough for MPL although I highly doubt even in that case it would be good enough for all the other Boost libraries that use Boost PP. As I have expressed in the past this is a miasma created by the clang team trying to accomodate Microsoft and VC++, as well as Microsoft wanting to use clang and their hybridized and buggy VC++ like preprocessor. This would have all been avoided if Microsoft had not created their own non-standard C++ preprocessor and held onto it for over a quarter of a century.
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... So, as I suspected, detecting -fno-ms-compatibility using __GNUC__ makes things worse. -# elif defined(_MSC_VER) && defined(__clang__) && defined(__GNUC__) // -fno-ms-compatibility mode +# elif defined(_MSC_VER) && defined(__clang__) -# elif defined(_MSC_VER) && defined(__clang__) && defined(__GNUC__) // -fno-ms-compatibility mode +# elif defined(_MSC_VER) && defined(__clang__) -# if defined _MSC_VER && _MSC_VER >= 1400 && !(defined(__clang__) && defined(__GNUC__)) && (defined(__clang__) || defined(__INTELLISENSE__) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) || !(defined __EDG__ || defined __GCCXML__ || defined __CUDACC__ || defined __PATHSCALE__ || defined __DMC__ || defined __CODEGEARC__ || defined __BORLANDC__ || defined __MWERKS__ || defined __SUNPRO_CC || defined __HP_aCC || defined __MRC__ || defined __SC__ || defined __IBMCPP__ || defined __PGI)) +# if defined _MSC_VER && _MSC_VER >= 1400 && !(defined(__clang__)) && (defined(__clang__) || defined(__INTELLISENSE__) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) || !(defined __EDG__ || defined __GCCXML__ || defined __CUDACC__ || defined __PATHSCALE__ || defined __DMC__ || defined __CODEGEARC__ || defined __BORLANDC__ || defined __MWERKS__ || defined __SUNPRO_CC || defined __HP_aCC || defined __MRC__ || defined __SC__ || defined __IBMCPP__ || defined __PGI)) The failing test is seq.cpp, with clang-linux.compile.c++.without-pth ..\..\bin.v2\libs\preprocessor\test\seq.test\clang-linux-14.1\debug\seq.obj In file included from test\seq.cpp:14: ..\..\libs/preprocessor/test/seq.cxx:213:42: error: too few arguments provided to function-like macro invocation BEGIN BOOST_PP_IS_EMPTY(BOOST_PP_LIST_AT(BOOST_PP_SEQ_TO_LIST(SEQ_NONE),0)) == 1 END No idea why only seq.cpp fails, as seq.c should be the same.
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.
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.
Actually no, it was because I needed to set _MSC_VER using -fmsc-version=1910. 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-linux.link ..\..\bin.v2\libs\preprocessor\test\config_info.test\clang-linux-4.0\debug\config_info.exe clang version 4.0.0 (tags/RELEASE_400/final) Target: i686-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "link.exe" "-out:..\\..\\bin.v2\\libs\\preprocessor\\test\\config_info.test\\clang-linux-4.0\\debug\\config_info.exe" -defaultlib:libcmt -nologo -debug --start-group "..\\..\\bin.v2\\libs\\preprocessor\\test\\config_info.test\\clang-linux- 4.0\\debug\\config_info.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) about which problem I can't find anything sensible.
Not sure why you'd want to use clang-win at present; I use clang-linux for everything.
So here's why, I suppose. Either way, I can't link, but at least the PP lib works (once the __GNUC__ checks are removed).
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.
On 3/26/2017 4:06 AM, Peter Dimov via Boost wrote:
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.
I did forget about "cflags=-fno-ms-compatibility" in my testing. Now I see that with both "cxxflags=-fno-ms-compatibility" and "cflags=-fno-ms-compatibility" the Boost PP tests all pass for clang using -fno-ms-compatibility and the clang-win toolset. Well I am certainly glad it worked and that clang targeting VC++ using -fno-ms-compatibility does work with my latest fix of Boost PP on the develop branch. Since that update only affects Boost PP when using clang in -fno-ms-compatibility mode ( aka clang targeting VC++ with -fno-ms-compatibility turned on ) I wonder If it is not too late to get it into the 'master' branch for the upcoming 1.64 release. Of course the Boost PP regression tests on the develop branch will not have cycled yet, but this fix may be important for VC++ developers wanting to use clang/C2 and Boost. However there are still some problems with the clang-win jam file which I am not experienced enough with Boost Build to solve, so others will need to figure them out. These are some PRs for Boost Build relating to those problems. You seem to be using the clang.jam file instead. I do not know how you are supposed to get that to work with clang targeting VC++ or clang/C2, 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.
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__.
On 3/26/2017 7:59 AM, Peter Dimov via Boost wrote:
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__.
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 ? What about the so-called emulation by clang of the non-standard VC++ preprocessor ? it does not work of course but you still want me to ignore it completely and consider that clang targeting VC++ ( aka clang-cl in clang for Windows ) uses a C++ standard preprocessor ?
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.
On 3/26/2017 8:28 AM, Peter Dimov via Boost wrote:
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.
You are absolutely correct and I have updated Boost PP on the 'develop' branch accordingly. I did see a few errors testing clang 3.8.1 clang-cl, but with clang 3.9.1 clang-cl, clang 4.0 clang-cl, and the latest clang built from source clang-cl all Boost PP tests passed. I did use clang-win.jam. How did you get just clang.jam to work ? Doesn't it need VC++ support when using clang-cl ?
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.
On 3/26/2017 12:10 PM, Peter Dimov via Boost wrote:
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.
That works fine for the Boost PP tests. I will have to try it with other libraries, like MPL, but hopefully it is an answer to Paul's original problem using my latest Boost PP fix on 'develop'. I also tried invoking clang-cl instead of clang++, but it failed miserably because it did was not able to process the options generated by the clang-linux.jam file.
-----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 <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.exe for lack of <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.obj... ...skipped <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.run for lack of <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.exe... ...failed updating 1 target... ...skipped 3 targets... ...updated 2 targets...
Paul A. Bristow wrote:
Now I get something as bad - back to missing the cstddef file.
I honestly have no idea why you have this problem and I do not. Clang finds the VC include directories for me.
PS You didn't say if I really needed the most recent March 2017 VS update?
It's true that I have VS 2017 installed and Clang finds and uses it, but Edward reports in the other message that VS 2015 works for him (when setting -msc-version=1900 as appropriate.)
I've tried adding to user_config.jam
<cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"
The correct way to set the include path is with <include>"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include" although I'm not sure about the quoting. If that doesn't work, you could try double-quoting: <include>"\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include\""
-----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 <boost@lists.boost.org> 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
On 3/27/2017 9:57 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 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 ???
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".
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 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
participants (4)
-
degski -
Edward Diener -
Paul A. Bristow -
Peter Dimov