current situation with clang-cl?
some of my project using boost building with clang-cl but there are still some libraries that don't is there any official interest in supporting clang-cl or is it up to a library maintainer to support it? many project of mine building better and better, boost 1.73 currently is neary full useable with clang-cl without any problems today i tried to compile a 600KLOC project and it failed with the same problem Libreoffice got they are using a patch to "fix" its used boost version https://github.com/LibreOffice/core/blob/62808ef28e05eee4945a6a15d981350d130... https://github.com/boostorg/thread/issues/286 "clang-cl defines _MSC_VER by ms-compatibility but BOOST_MSVC will not be set." still a problem? there are some Issues reported but i don't know if fixes are wanted of if there is a strategy to support clang-cl out of the box
On 2020-08-11 18:24, Dennis Luehring via Boost wrote:
some of my project using boost building with clang-cl but there are still some libraries that don't
is there any official interest in supporting clang-cl or is it up to a library maintainer to support it?
There are no official testers running clang-cl, as far as I can see: https://www.boost.org/development/tests/develop/developer/summary.html However, CI configs for many libraries do include clang-cl jobs. So the support is each library maintainer's initiative. You can try filing PRs improving support for clang-cl to given libraries. Older versions of clang-cl were too broken to be supported, so don't expect those to work. And probably don't bother creating PRs adding workarounds for them. Newer versions seem to be better, though.
https://github.com/boostorg/thread/issues/286
"clang-cl defines _MSC_VER by ms-compatibility but BOOST_MSVC will not be set." still a problem?
BOOST_MSVC is not supposed to be defined for clang-cl.
small test with 1.74-beta looks better --------- #include <boost/archive/xml_iarchive.hpp> #include <boost/smart_ptr/shared_ptr.hpp> int main() { return 0; } --------- does compile without a problem with current 1.74-beta but now the linker is telling me that i need to have a clangw10 build of boost lld-link : error : could not open 'libboost_serialization-clangw10-mt-gd-x32-1_74.lib': no such file or directory the nature of clang-cl is a easy binary and feature compatible drop in replacement for the microsoft-cl until 1.74 there was no need to prepare a descent build of boost for clang i switch multiple times per day between microsoft-cl and clang-cl (because clang-cl gives better diagnostics) this switching works with all (~10-20 libs) of my non-boost third party libs without the need for a descent build - why do boost need that?, or did i configure something wrong? Am 11.08.2020 um 21:51 schrieb Andrey Semashev via Boost:
On 2020-08-11 18:24, Dennis Luehring via Boost wrote:
some of my project using boost building with clang-cl but there are still some libraries that don't
is there any official interest in supporting clang-cl or is it up to a library maintainer to support it?
There are no official testers running clang-cl, as far as I can see:
https://www.boost.org/development/tests/develop/developer/summary.html
However, CI configs for many libraries do include clang-cl jobs. So the support is each library maintainer's initiative.
You can try filing PRs improving support for clang-cl to given libraries.
Older versions of clang-cl were too broken to be supported, so don't expect those to work. And probably don't bother creating PRs adding workarounds for them. Newer versions seem to be better, though.
https://github.com/boostorg/thread/issues/286
"clang-cl defines _MSC_VER by ms-compatibility but BOOST_MSVC will not be set." still a problem?
BOOST_MSVC is not supposed to be defined for clang-cl.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dennis Luehring wrote:
until 1.74 there was no need to prepare a descent build of boost for clang
Looking at the history of boost/config/auto_link.hpp, 1.70 didn't autolink under Clang at all, and since 1.71 Clang autolinks to clangw libraries. So I don't see why 1.73 and 1.74 would differ. If you want to override this, #define BOOST_LIB_TOOLSET to vc141 (if using 2017.)
Looking at the history of boost/config/auto_link.hpp, 1.70 didn't autolink under Clang at all
and since 1.71 Clang autolinks to clangw libraries. So I don't see why 1.73 and 1.74 would differ.
Clang or Clang-cl? a freshly build 1.73 and 1.74-rc2 showing exact that behavior both boost versions are only build with vc141 - there are only vc141 libs available if using boost 1.73 it makes no difference in building with microsoft-cl or clang-cl if using boost 1.74 - boost will ask for clangw10 libs Am 12.08.2020 um 16:08 schrieb Peter Dimov via Boost:
Dennis Luehring wrote:
until 1.74 there was no need to prepare a descent build of boost for clang
Looking at the history of boost/config/auto_link.hpp, 1.70 didn't autolink under Clang at all, and since 1.71 Clang autolinks to clangw libraries. So I don't see why 1.73 and 1.74 would differ.
If you want to override this, #define BOOST_LIB_TOOLSET to vc141 (if using 2017.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dennis Luehring wrote:
a freshly build 1.73 and 1.74-rc2 showing exact that behavior
both boost versions are only build with vc141 - there are only vc141 libs available
if using boost 1.73 it makes no difference in building with microsoft-cl or clang-cl
if using boost 1.74 - boost will ask for clangw10 libs
That's not what I'm seeing here (although I tried with VS2019 and LLVM 9.) When using Boost 1.73, and your test program, I get 1>lld-link : error : could not open 'libboost_serialization-clangw9-mt-gd-x64-1_73.lib': no such file or directory which matches my expectation. Defining BOOST_LIB_DIAGNOSTIC yields: 1>In file included from testbed2019.cpp:3: 1>In file included from D:\boost_1_73_0\boost/archive/xml_iarchive.hpp:22: 1>In file included from D:\boost_1_73_0\boost/archive/detail/auto_link_archive.hpp:45: 1>D:\boost_1_73_0\boost/config/auto_link.hpp(441): warning : Linking to lib file: libboost_serialization-clangw9-mt-gd-x64-1_73.lib [-W#pragma-messages] Again, as expected, based on the contents of auto_link.hpp.
That's not what I'm seeing here (although I tried with VS2019 and LLVM 9.) When using Boost 1.73, and your test program, I get
it always worked for me without any special settings (im on VS2017 and using the LLVM-VStudio integrationhttps://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-tool... <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>) i've never need to change anything in my projects beside installing latest LLVM/clang + extension and switching the compiler in every of my private and customer projects - its the first time with 1.74 that it does not work out of the box i've never set any auto-link defines and using clang-cl on daily basis for some years now Am 12.08.2020 um 16:47 schrieb Peter Dimov via Boost:
Dennis Luehring wrote:
a freshly build 1.73 and 1.74-rc2 showing exact that behavior
both boost versions are only build with vc141 - there are only vc141 libs available
if using boost 1.73 it makes no difference in building with microsoft-cl or clang-cl
if using boost 1.74 - boost will ask for clangw10 libs
That's not what I'm seeing here (although I tried with VS2019 and LLVM 9.) When using Boost 1.73, and your test program, I get
1>lld-link : error : could not open 'libboost_serialization-clangw9-mt-gd-x64-1_73.lib': no such file or directory
which matches my expectation.
Defining BOOST_LIB_DIAGNOSTIC yields:
1>In file included from testbed2019.cpp:3: 1>In file included from D:\boost_1_73_0\boost/archive/xml_iarchive.hpp:22: 1>In file included from D:\boost_1_73_0\boost/archive/detail/auto_link_archive.hpp:45: 1>D:\boost_1_73_0\boost/config/auto_link.hpp(441): warning : Linking to lib file: libboost_serialization-clangw9-mt-gd-x64-1_73.lib [-W#pragma-messages]
Again, as expected, based on the contents of auto_link.hpp.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dennis Luehring wrote:
it always worked for me without any special settings (im on VS2017 and using the LLVM-VStudio integrationhttps://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-tool... <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>)
i've never need to change anything in my projects beside installing latest LLVM/clang + extension and switching the compiler in every of my private and customer projects - its the first time with 1.74 that it does not work out of the box
i've never set any auto-link defines and using clang-cl on daily basis for some years now
What happens when you define BOOST_LIB_DIAGNOSTIC? What's the full compiler output when building your test program?
im offically confused now i can't build any of my former projects using 1.73 or 1.74 only 1.69 works without changes (maybe also 1.70+) so mabye i didn't properbly checked the builds when i upgraded to 1.73 IDE: VS2017, clang-cl 10.0.0, LLVM Visual Studio Extension, Boost 1.69,1.73,1.74 - freshly build using Boost 1.69 projects builds with microsoft-cl and clang-cl without definining BOOST_LIB_TOOLSET for Boost 1.73,1.74 i need to set BOOST_LIB_TOOLSET to "vc141" example: ---------------------- //#define BOOST_LIB_TOOLSET "vc141" // only needed for 1.73 and 1.74, not for 1.69 #include <boost/regex.hpp> /* definition to expand macro then apply to pragma message */ #define VALUE_TO_STRING(x) #x #define VALUE(x) VALUE_TO_STRING(x) #define VAR_NAME_VALUE(var) #var "=" VALUE(var) #ifdef _MSC_VER #pragma message(VAR_NAME_VALUE(_MSC_VER)) #pragma message(VAR_NAME_VALUE(_MSC_FULL_VER)) #endif #ifdef _clang__ #pragma message(VAR_NAME_VALUE(__clang__)) #pragma message(VAR_NAME_VALUE(__clang_version__)) #endif #ifdef BOOST_MSVC #pragma message(VAR_NAME_VALUE(BOOST_MSVC)) #endif #ifdef BOOST_VERSION #pragma message(VAR_NAME_VALUE(BOOST_VERSION)) #endif #ifdef BOOST_LIB_TOOLSET #pragma message(VAR_NAME_VALUE(BOOST_LIB_TOOLSET)) #endif int main() { return 0; } ---------------------- Boost 1.69 microsoft-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>_MSC_VER=1916 1>_MSC_FULL_VER=191627043 1>BOOST_MSVC=1916 1>BOOST_VERSION=106900 1>BOOST_LIB_TOOLSET="vc141" 1> Creating library D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.lib and object D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.exp 1>clang_cl_tests.vcxproj -> D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.exe ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== clang-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp(12): warning : _MSC_VER=1916 [-W#pragma-messages] 1>clang_cl_tests.cpp(13): warning : _MSC_FULL_VER=191627043 [-W#pragma-messages] 1>clang_cl_tests.cpp(23): warning : BOOST_VERSION=106900 [-W#pragma-messages] 1>lld-link : warning : /debug:fastlink unsupported; using /debug:full 1>clang_cl_tests.vcxproj -> D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.exe 1>Done building project "clang_cl_tests.vcxproj". ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== Boost 1.73 microsoft-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_73.lib 1>_MSC_VER=1916 1>_MSC_FULL_VER=191627043 1>BOOST_MSVC=1916 1>BOOST_VERSION=107300 1>BOOST_LIB_TOOLSET="vc141" 1>clang_cl_tests.vcxproj -> D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.exe ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== clang-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp(12): warning : _MSC_VER=1916 [-W#pragma-messages] 1>clang_cl_tests.cpp(13): warning : _MSC_FULL_VER=191627043 [-W#pragma-messages] 1>clang_cl_tests.cpp(23): warning : BOOST_VERSION=107300 [-W#pragma-messages] 1>clang_cl_tests.cpp(26): warning : BOOST_LIB_TOOLSET="clangw" "10" [-W#pragma-messages] 1>lld-link : warning : /debug:fastlink unsupported; using /debug:full 1>lld-link : error : could not open 'libboost_regex-clangw10-mt-gd-x32-1_73.lib': no such file or directory 1>Done building project "clang_cl_tests.vcxproj" -- FAILED. ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== Boost 1.74 microsoft-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_74.lib 1>_MSC_VER=1916 1>_MSC_FULL_VER=191627043 1>BOOST_MSVC=1916 1>BOOST_VERSION=107400 1>BOOST_LIB_TOOLSET="vc141" 1>clang_cl_tests.vcxproj -> D:\temp\clang_cl_tests\clang_cl_tests\Debug\clang_cl_tests.exe ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== clang-cl 1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp(12): warning : _MSC_VER=1916 [-W#pragma-messages] 1>clang_cl_tests.cpp(13): warning : _MSC_FULL_VER=191627043 [-W#pragma-messages] 1>clang_cl_tests.cpp(23): warning : BOOST_VERSION=107400 [-W#pragma-messages] 1>clang_cl_tests.cpp(26): warning : BOOST_LIB_TOOLSET="clangw" "10" [-W#pragma-messages] 1>lld-link : warning : /debug:fastlink unsupported; using /debug:full 1>lld-link : error : could not open 'libboost_regex-clangw10-mt-gd-x32-1_74.lib': no such file or directory 1>Done building project "clang_cl_tests.vcxproj" -- FAILED. ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== Am 12.08.2020 um 17:12 schrieb Peter Dimov via Boost:
Dennis Luehring wrote:
it always worked for me without any special settings (im on VS2017 and using the LLVM-VStudio integrationhttps://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-tool... <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>)
i've never need to change anything in my projects beside installing latest LLVM/clang + extension and switching the compiler in every of my private and customer projects - its the first time with 1.74 that it does not work out of the box
i've never set any auto-link defines and using clang-cl on daily basis for some years now
What happens when you define BOOST_LIB_DIAGNOSTIC? What's the full compiler output when building your test program?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dennis Luehring wrote:
Boost 1.69
microsoft-cl
1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>_MSC_VER=1916
...
clang-cl
1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp(12): warning : _MSC_VER=1916 [-W#pragma-messages]
Yes, as I said, Clang doesn't autolink at all in 1.69. Autolink for Clang was enabled in 1.71. https://github.com/boostorg/config/commit/a18911902dff03f37582696a13bf60768c...
thank for clearing that up - two times :) last question: what is the reason for not setting BOOST_MSVC and BOOST_LIB_TOOLSET if _MSC_VER && __clang__ is set? this way clang-cl could really work as a drop in replacement for microsoft-cl without changing anything in the project are there just too many bugs with clang-cl's microsoft compatiblity or is the microsoft-cl and clang-cl version mapping problematic (which version of clang-cl is compatible enough with what version of mircosoft-cl?) Am 12.08.2020 um 20:28 schrieb Peter Dimov via Boost:
Dennis Luehring wrote:
Boost 1.69
microsoft-cl
1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>Linking to lib file: libboost_regex-vc141-mt-gd-x32-1_69.lib 1>_MSC_VER=1916
...
clang-cl
1>------ Rebuild All started: Project: clang_cl_tests, Configuration: Debug Win32 ------ 1>clang_cl_tests.cpp(12): warning : _MSC_VER=1916 [-W#pragma-messages]
Yes, as I said, Clang doesn't autolink at all in 1.69. Autolink for Clang was enabled in 1.71.
https://github.com/boostorg/config/commit/a18911902dff03f37582696a13bf60768c...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2020-08-13 10:36, Dennis Luehring via Boost wrote:
thank for clearing that up - two times :)
last question:
what is the reason for not setting BOOST_MSVC and BOOST_LIB_TOOLSET if _MSC_VER && __clang__ is set? this way clang-cl could really work as a drop in replacement for microsoft-cl without changing anything in the project
are there just too many bugs with clang-cl's microsoft compatiblity or is the microsoft-cl and clang-cl version mapping problematic (which version of clang-cl is compatible enough with what version of mircosoft-cl?)
BOOST_MSVC indicates genuine MSVC. While clang-cl tries to implement MSVC features, it is a different compiler with its own bugs and features not present in MSVC. And vise versa - not all MSVC bugs are present in clang-cl. Also, please don't top-post. https://www.boost.org/community/policy.html#quoting
Am 13.08.2020 um 11:53 schrieb Andrey Semashev via Boost:
BOOST_MSVC indicates genuine MSVC. While clang-cl tries to implement MSVC features, it is a different compiler with its own bugs and features not present in MSVC. And vise versa - not all MSVC bugs are present in clang-cl.
reasonable decision
Also, please don't top-post.
never again thx dennis
On 13/08/2020 08:36, Dennis Luehring via Boost wrote:
thank for clearing that up - two times :)
last question:
what is the reason for not setting BOOST_MSVC and BOOST_LIB_TOOLSET if _MSC_VER && __clang__ is set? this way clang-cl could really work as a drop in replacement for microsoft-cl without changing anything in the project
The whole point of BOOST_MSVC is to signal that this really is msvc, since we already have _MSC_VER for ms compatible compilers. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
participants (4)
-
Andrey Semashev -
Dennis Luehring -
John Maddock -
Peter Dimov