i've got a working LLVM 14.x/clang-cl installation (means working with
cmake/ninja etc. with my non boost projects)
and working boost builds for 32/64 bit with VS2017,2019,2022,mingw aka a
"good working environment"
for my boost projects i tried to use my VS2017 built libs by forcing the
toolkit name with set(Boost_COMPILER "vc141") in my root CMakeLists.txt
cmake -G Ninja -DCMAKE_C_COMPILER="C:/Program
Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program
Files/LLVM/bin/clang-cl.exe" ../myproject
that does not work for all linking (sometimes lld-link.exe complains
about missing libboost_unit_test_framework-clangw14-mt-gd-x64-1_79.lib
etc. (with the wrong "clangw14" in the name)
im always using boosts own cmake configuration using the CONFIG
parameter with cmakes find_package
find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework
filesystem system)
and i've checked that Boost_COMPILER is always "vc141" before
find_package call
do i miss something or does Boost_COMPILER does not work properly with
boost own cmake config ?
the other idea was to build boost directly with clang-cl in an VS2017
build environment
inside my current boost build folder (where are the lib32-msvc-14.1,
lib64-msvc-14.1 etc. b2 build folders resist)
i tried to build with toolkit=clang
without and beeing in a VS2017 build environment
with C:\Program Files\LLVM\bin in my path
using that b2 commandline for building
b2 -j%NUMBER_OF_PROCESSORS% toolset=clang address-model=64
--stagedir=.\lib64-clang-14.0 --build-dir=.\__build
--build-type=complete threading=multi architecture=x86 stage
--with-date_time --with-graph --with-nowide --with-test --width-config
--with-system --with-filesystem --with-serialization
but that fails with linker errors
(https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tool…)
any tutorial how to force building boost with clang-cl instead of cl
using the microsoft libraries etc. as usual?
there is no clang-cl or clangw toolkit setting available to my understanding
Quick announcement: I'm planning on dropping C++98 support for Boost.Locale. I.e. require e.g. Rvalue references and std::unique_ptr to reduce maintenance effort.
If anyone knows a reason to not do that please respond to https://github.com/boostorg/locale/issues/90
As per suggestion from Peter I'll add a warning for the upcoming release and will drop support in the next if there isn't anything in particular. Especially recent ICU headers already requiring C++11 is enough of a reason to not stick to the old stuff.
Regards
I can't spot where, but something has changed in the last couple of days
that has broken building quickbook:
https://app.circleci.com/pipelines/github/boostorg/math/635/workflows/33cd9…
../../../boost/container_hash/hash.hpp:654:30: error: call of overloaded 'hash_value(const boost::filesystem::path&)' is ambiguous
654 | return hash_value( val );
| ~~~~~~~~~~^~~~~~~
../../../boost/container_hash/hash.hpp:382:9: note: candidate: 'typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type boost::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type = long unsigned int]'
382 | hash_value( T const& v )
| ^~~~~~~~~~
In file included from /root/boost-local/boost/tools/quickbook/src/files.hpp:18,
from /root/boost-local/boost/tools/quickbook/src/files.cpp:10:
../../../boost/filesystem/path.hpp:1183:82: note: candidate: 'typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type boost::filesystem::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type = long unsigned int]'
1183 | inline typename boost::enable_if< boost::is_same< T, path >, std::size_t >::type hash_value(T const& p) BOOST_NOEXCEPT
In point of fact, those two overloads do look genuinely ambiguous to me,
so I'm not sure why this compiled before, or what changed to make it
fail now?
Ideas?
Thanks, John.
