Clang 600 and BOOST_SYSTEM_CONSTEXPR causes error_code.hpp compile failure.
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries. It comes to grief with these messages (the berbose gory details can be posted if anyone can help). In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This seems to be the ultimate cause I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) Is this because BOOST_SYSTEM_CONSTEXPR should not be defined? I note this in error_code.hpp #if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus >= 201700L // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835 # undef BOOST_SYSTEM_HAS_CONSTEXPR #endif should this undef list also include clang, and if so which versions 600? Or is there something about Boost.config and Codeblocks on Windows? Adding unconditional # undef BOOST_SYSTEM_HAS_CONSTEXPR seems to work. Suggestions welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 6/07/2018 03:12, Paul A. Bristow wrote:
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries.
It comes to grief with these messages (the berbose gory details can be posted if anyone can help).
In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This seems to be the ultimate cause
I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc )
Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
I think the issue is that BOOST_SYSTEM_CONSTEXPR is expected to expand to "constexpr" (according to the error you're getting) but is instead expanding to "". Normally the latter occurs in environments that don't support constexpr while the former occurs in environments that do; conversely I'd assume that BOOST_SYSTEM_REQUIRE_CONST_INIT would also be disabled in environments that don't support constexpr. So some of the defines appear to think that constexpr is supported while others think that it is not. Perhaps you can focus on what conditions drive each of these definitions? I don't know what the actual resolution to this is, but perhaps it helps?
On Thu, Jul 5, 2018 at 8:12 AM, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries.
It comes to grief with these messages (the berbose gory details can be posted if anyone can help).
In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
^~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_ initialization]] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ This seems to be the ultimate cause
I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc )
Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
I note this in error_code.hpp
#if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus
= 201700L // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835 # undef BOOST_SYSTEM_HAS_CONSTEXPR #endif
should this undef list also include clang, and if so which versions 600?
I *suspect* that this is a red herring - but not having access to a Windows box, I don't know that. * Clang defines __GNUC__ to 4 (for compatibility reasons), so this #ifdef should never fire under clang. * This block of code is to work around a bug in gcc that clang doesn't have. -- Marshall
Paul A. Bristow wrote:
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries.
I'll need more information than that, because the tests for System pass on Clang 6 on Travis. https://travis-ci.org/boostorg/system/jobs/398224285
It comes to grief with these messages (the berbose gory details can be posted if anyone can help).
In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance;
This path is only entered when BOOST_ERROR_CODE_HEADER_ONLY is defined, by the way.
I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc )
Either `BOOST_SYSTEM_CONSTEXPR` is not defined to `constexpr` - which doesn't make sense because otherwise line 409 won't be reached - or there's something else going on and the complete error log might help.
Is this because BOOST_SYSTEM_CONSTEXPR should not be defined?
It should be, for C++14 or later.
I note this in error_code.hpp
#if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus
= 201700L
This is now #if defined(__GNUC__) && (__GNUC__ == 7 && __GNUC_MINOR__ < 4) && __cplusplus >= 201700L because the GCC bug has been fixed for 7.4 and 8.1.
should this undef list also include clang, and if so which versions 600?
No.
On 07/07/2018 18:14, Peter Dimov via Boost wrote:
Paul A. Bristow wrote:
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries.
I'll need more information than that, because the tests for System pass on Clang 6 on Travis.
It's the windows build that's the issue, not Linux. Compiling from within the VC IDE using the clang installed LLVM-2014 toolset, and the full command line options: /GS /GL /W3 /Gy /Zc:wchar_t /I"m:\data\boost\boost" /Zi /Gm- /O2 /Fd"x64\Release\system.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\system.pch" I see: 1>clang-cl.exe : warning : argument unused during compilation: '/Gm-' [-Wunused-command-line-argument] 1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:16: 1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): error : constexpr constructor never produces a constant expression [-Winvalid-constexpr] 1> BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) 1> ^ 1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note: non-constexpr constructor 'error_category' cannot be used in a constant expression 1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION 1> ^ 1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19: 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(78,33): warning : 'strerror' is deprecated: This function or variable may be unsafe. Consider using strerror_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [-Wdeprecated-declarations] 1> const char * c_str = std::strerror( ev ); 1> ^ 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\string.h(180,16): note: 'strerror' has been explicitly marked deprecated here 1>_Check_return_ _CRT_INSECURE_DEPRECATE(strerror_s) 1> ^ 1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\vcruntime.h(269,55): note: expanded from macro '_CRT_INSECURE_DEPRECATE' 1> #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT( \ 1> ^ 1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\vcruntime.h(259,47): note: expanded from macro '_CRT_DEPRECATE_TEXT' 1>#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text)) 1> ^ 1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19: 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,73): error : variable does not have a constant initializer 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL system_error_category system_category_instance; 1> ^~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,1): note: required by 'require_constant_initialization' attribute here 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL system_error_category system_category_instance; 1>^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/error_code.hpp(392,44): note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' 1># define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] 1> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note: non-constexpr constructor 'error_category' cannot be used in a constant expression 1> BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) 1> ^ 1>m:\data\boost\boost\boost/system/error_code.hpp(252,70): note: in call to 'std_category(&system_category_instance)' 1> BOOST_SYSTEM_CONSTEXPR error_category() BOOST_SYSTEM_NOEXCEPT: std_cat_( this ) {} 1> ^ 1>m:\data\boost\boost\boost/system/error_code.hpp(370,28): note: in call to 'error_category()' 1> BOOST_SYSTEM_CONSTEXPR system_error_category() BOOST_SYSTEM_NOEXCEPT 1> ^ 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(458,73): note: in call to 'system_error_category()' 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL system_error_category system_category_instance; 1> ^ 1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION 1> ^ 1>In file included from ..\..\..\..\libs\system\src\error_code.cpp:19: 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,74): error : variable does not have a constant initializer 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL generic_error_category generic_category_instance; 1> ^~~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,1): note: required by 'require_constant_initialization' attribute here 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL generic_error_category generic_category_instance; 1>^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/error_code.hpp(392,44): note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' 1># define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] 1> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1>m:\data\boost\boost\boost/system/error_code.hpp(226,41): note: non-constexpr constructor 'error_category' cannot be used in a constant expression 1> BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) 1> ^ 1>m:\data\boost\boost\boost/system/error_code.hpp(252,70): note: in call to 'std_category(&generic_category_instance)' 1> BOOST_SYSTEM_CONSTEXPR error_category() BOOST_SYSTEM_NOEXCEPT: std_cat_( this ) {} 1> ^ 1>m:\data\boost\boost\boost/system/error_code.hpp(354,28): note: in call to 'error_category()' 1> BOOST_SYSTEM_CONSTEXPR generic_error_category() BOOST_SYSTEM_NOEXCEPT 1> ^ 1>m:\data\boost\boost\boost/system/detail/error_code.ipp(459,74): note: in call to 'generic_error_category()' 1>BOOST_SYSTEM_REQUIRE_CONST_INIT BOOST_SYSTEM_DECL generic_error_category generic_category_instance; 1> ^ 1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION 1> ^ 1>1 warning and 3 errors generated. I believe the error is correct as well: class std_category has virtual member functions and so no constructor can ever be constexpr as the type can never be a literal. HTH, John. --- This email has been checked for viruses by AVG. https://www.avg.com
John Maddock wrote:
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
This commented-out constexpr (in the 2015 headers) is the problem, thanks. Now how do we work around it...
I believe the error is correct as well: class std_category has virtual member functions and so no constructor can ever be constexpr as the type can never be a literal.
No.
John Maddock wrote:
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
This commented-out constexpr (in the 2015 headers) is the problem, thanks. Now how do we work around it...
The problem here is that Clang can pick up and use any MSVC headers it finds depending on who knows what search algorithm, and to work around the commented-out constexpr I need to detect that it uses the 2015 STL (because the 2017 STL would presumably have the constexpr, although I haven't checked all of its flavors.) I'm not sure that checking _MSC_VER would be enough, as I suspect that Clang doesn't take the compatibility version into account when searching for headers to use. There's _CPPLIB_VER, but I can't find what values correspond to what versions. Boost.Config says that certain things appeared in 520, 540, 610, 650, but what releases do these correspond to? In addition, Microsoft stopped increasing _CPPLIB_VER at some point (starting with 2017?), then added their own macro (a welcome addition) but I can't recall how that was called, when it was added, and can find no info on that either. :-) It ain't easy.
On 8 July 2018 at 17:42, Peter Dimov via Boost <boost@lists.boost.org> wrote:
I'm not sure that checking _MSC_VER would be enough, as I suspect that Clang doesn't take the compatibility version into account when searching for headers to use.
https://github.com/boostorg/regex/issues/44 was a fix in regex. In addition, Microsoft stopped increasing _CPPLIB_VER at some point
(starting with 2017?), then added their own macro (a welcome addition) but I can't recall how that was called, when it was added, and can find no info on that either.
It's gonna be updated and maintained (I think 15.8). degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 8 July 2018 at 18:17, degski <degski@gmail.com> wrote:
https://github.com/boostorg/regex/issues/44 was a fix in regex.
A comment to that, clang-win can be positively identified, iff both __GNUC__ and _MSC_VER are defined (it's odd, but unique). clang-cl defines "_MSC_VER=0" iff -fmsc-version is not set. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 8 July 2018 at 17:42, Peter Dimov via Boost <boost@lists.boost.org> wrote:
I'm not sure that checking _MSC_VER would be enough, as I suspect that Clang doesn't take the compatibility version into account when searching for headers to use.
Iff one uses the installer, clang picks it up from the installed .props file(s), see attached. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 08/07/2018 15:42, Peter Dimov via Boost wrote:
John Maddock wrote:
1>C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\include\system_error(168,18): note: declared here 1> /* constexpr */ error_category() _NOEXCEPT // TRANSITION
This commented-out constexpr (in the 2015 headers) is the problem, thanks. Now how do we work around it...
The problem here is that Clang can pick up and use any MSVC headers it finds depending on who knows what search algorithm, and to work around the commented-out constexpr I need to detect that it uses the 2015 STL (because the 2017 STL would presumably have the constexpr, although I haven't checked all of its flavors.)
I preprocessed the source and it's picking up the latest headers for me: m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error and I still see: class error_category { // categorize an error public: /* constexpr */ error_category() _NOEXCEPT // TRANSITION { // default constructor _Addr = reinterpret_cast<uintptr_t>(this); } In that header. Defines wise we have: Clang version 6.0.0 (tags/RELEASE_600/final) _CPPUNWIND =1 __cplusplus =201402L _WIN32 =1 _WIN64 =1 _CPPRTTI =1 _CPPUNWIND =1 _DLL =1 _M_AMD64 =100 _M_X64 =100 _MSC_BUILD =1 _MSC_EXTENSIONS =1 _MSC_VER =1900 _MSC_FULL_VER =190000000 _MSVC_LANG =201402L _MT =1 _NATIVE_WCHAR_T_DEFINED =1 __VERSION__ ="4.2.1 Compatible Clang 6.0.0 (tags/RELEASE_600/final)" Dinkumware standard library version 650 _CPPLIB_VER =650 _GLOBAL_USING =1 _HAS_EXCEPTIONS =1 _HAS_CXX17 =0 _HAS_AUTO_PTR_ETC =1 _HAS_OLD_IOSTREAMS_MEMBERS =1 _HAS_FUNCTION_ASSIGN =1 _HAS_TR1_NAMESPACE =1 _HAS_IDENTITY_STRUCT =1 _ITERATOR_DEBUG_LEVEL =2 _HAS_ITERATOR_DEBUGGING =1 _ITERATOR_DEBUG_ARRAY_OVERLOADS =1 Not sure if this helps, John. --- This email has been checked for viruses by AVG. https://www.avg.com
John Maddock wrote:
I preprocessed the source and it's picking up the latest headers for me: m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error
and I still see:
class error_category { // categorize an error public: /* constexpr */ error_category() _NOEXCEPT // TRANSITION
I have 14.14.26428 and I see the same. :-/ Well this sure simplifies version checking for this particular issue if nothing else.
Defines wise we have: ... _CPPLIB_VER =650
After looking at the config_info output from the test matrix, the values are, for reference: _CPPLIB_VER=405: msvc-8.0 _CPPLIB_VER=505: msvc-9.0 _CPPLIB_VER=520: msvc-10.0 _CPPLIB_VER=540: msvc-11.0 _CPPLIB_VER=610: msvc-12.0 _CPPLIB_VER=650: msvc-14.0 and above The new macros are: "The STL now identifies itself with two macros, defined by including any STL header (e.g. <ciso646>). _MSVC_STL_VERSION is defined as 141 and will remain that way for the VS 2017 v141 toolset series. _MSVC_STL_UPDATE is defined as 201709 in VS 2017 15.5, and will be increased as features are added in future updates. (The year-month typically won’t correspond to an update’s release date. Our process for updating this macro is “we’re checking in std::meow() and it’s now October, so we need to change the value”, and depending on branch/merge timing, it might take a month or more to ship.) The value for VS 2017 15.6 is not yet set in stone, but it will be 201711 or greater." https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-1... and I was going to suggest we add them, but someone already did: https://github.com/boostorg/config/commit/d5986d697ca534e18d192bd28b8c1177fe... Incidentally... while looking into this, I encountered https://github.com/boostorg/config/commit/15a0c119a13938bd00b99273e6fb876ff0... which uses the compiler version to decide on a library feature. It will define BOOST_NO_CXX17_STD_APPLY under Clang. It might be a good idea to codify the above knowledge somehow into a BOOST_MSSTL_VERSION macro and then check that instead of _MSC_VER or BOOST_MSVC which generally doesn't work with Clang.
On Sun, Jul 8, 2018 at 12:54 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
John Maddock wrote:
I preprocessed the source and it's picking up the latest headers for me:
m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error
and I still see:
class error_category { // categorize an error public: /* constexpr */ error_category() _NOEXCEPT // TRANSITION
I have 14.14.26428 and I see the same. :-/
Well this sure simplifies version checking for this particular issue if nothing else.
Defines wise we have: ... _CPPLIB_VER =650
After looking at the config_info output from the test matrix, the values are, for reference:
_CPPLIB_VER=405: msvc-8.0 _CPPLIB_VER=505: msvc-9.0 _CPPLIB_VER=520: msvc-10.0 _CPPLIB_VER=540: msvc-11.0 _CPPLIB_VER=610: msvc-12.0 _CPPLIB_VER=650: msvc-14.0 and above
The new macros are:
"The STL now identifies itself with two macros, defined by including any STL header (e.g. <ciso646>). _MSVC_STL_VERSION is defined as 141 and will remain that way for the VS 2017 v141 toolset series. _MSVC_STL_UPDATE is defined as 201709 in VS 2017 15.5, and will be increased as features are added in future updates. (The year-month typically won’t correspond to an update’s release date. Our process for updating this macro is “we’re checking in std::meow() and it’s now October, so we need to change the value”, and depending on branch/merge timing, it might take a month or more to ship.) The value for VS 2017 15.6 is not yet set in stone, but it will be 201711 or greater."
https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-1...
and I was going to suggest we add them, but someone already did:
https://github.com/boostorg/config/commit/d5986d697ca534e18d192bd28b8c1177fe...
Incidentally... while looking into this, I encountered
https://github.com/boostorg/config/commit/15a0c119a13938bd00b99273e6fb876ff0...
which uses the compiler version to decide on a library feature. It will define BOOST_NO_CXX17_STD_APPLY under Clang.
It might be a good idea to codify the above knowledge somehow into a BOOST_MSSTL_VERSION macro and then check that instead of _MSC_VER or BOOST_MSVC which generally doesn't work with Clang.
It sounds like Boost.Predef could help here, since it can detect Dinkumware? - Jim
Paul A. Bristow wrote:
Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries.
It comes to grief with these messages (the berbose gory details can be posted if anyone can help).
This should now be fixed on develop. Let me know how it goes.
participants (7)
-
degski -
Gavin Lambert -
James E. King III -
John Maddock -
Marshall Clow -
Paul A. Bristow -
Peter Dimov