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
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-tool...) 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-tool...)
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
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-tool...)
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