Problem building Ceph 14.2.15 with libboost 1.74.0
Hi, I'm the Debian package maintainer for Ceph. Ceph currently fails to build with latest libbost. Here's the build log: /root/ceph/src/common/async/completion.h:194:29: error: 'boost::asio::executor_work_guard<boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0>
, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0>
, void>::executor_type' {aka 'class boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> , boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0> '} has no member named 'defer'; did you mean 'prefer'? 194 | w.second.get_executor().defer(std::move(f), alloc2);
and 3 more like this. The code doing this is in src/common/async/completion.h: void destroy_defer(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().defer(std::move(f), alloc2); } void destroy_dispatch(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().dispatch(std::move(f), alloc2); } void destroy_post(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().post(std::move(f), alloc2); } Has the boost API changed? If so, how to fix the above code? Thanks a lot to anyone helping me fixing this, Cheers, Thomas Goirand (zigo)
On 1/7/21 4:51 PM, Thomas Goirand via Boost wrote:
Hi,
I'm the Debian package maintainer for Ceph. Ceph currently fails to build with latest libbost. Here's the build log:
/root/ceph/src/common/async/completion.h:194:29: error: 'boost::asio::executor_work_guard<boost::asio::execution::any_executor<
'} has no member named 'defer'; did you mean 'prefer'? 194 | w.second.get_executor().defer(std::move(f), alloc2);
and 3 more like this. The code doing this is in src/common/async/completion.h:
void destroy_defer(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().defer(std::move(f), alloc2); }
Has the boost API changed? If so, how to fix the above code?
This seems to be caused by some changes in Boost.ASIO, in particular its executors API. I'm not the maintainer and I have no knowledge of that part of Boost.ASIO, but you could try using the standalone defer algorithm. Instead of: w.second.get_executor().defer(std::move(f), alloc2); try: boost::asio::defer(w.second.get_executor(), std::move(f)); You will need to add #include <boost/asio/defer.hpp> for this. Note: the above is completely untested. You may want to ask for help regarding ASIO on its GitHub project (https://github.com/chriskohlhoff/asio/). Boost.ASIO is auto-generated from ASIO and has the same API sans namespaces and macro names.
On 1/7/21 9:22 PM, Andrey Semashev via Boost wrote:
On 1/7/21 4:51 PM, Thomas Goirand via Boost wrote:
Hi,
I'm the Debian package maintainer for Ceph. Ceph currently fails to build with latest libbost. Here's the build log:
/root/ceph/src/common/async/completion.h:194:29: error: 'boost::asio::executor_work_guard<boost::asio::execution::any_executor<
'} has no member named 'defer'; did you mean 'prefer'? 194 | w.second.get_executor().defer(std::move(f), alloc2);
and 3 more like this. The code doing this is in src/common/async/completion.h:
void destroy_defer(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().defer(std::move(f), alloc2); }
Has the boost API changed? If so, how to fix the above code?
This seems to be caused by some changes in Boost.ASIO, in particular its executors API. I'm not the maintainer and I have no knowledge of that part of Boost.ASIO, but you could try using the standalone defer algorithm.
Instead of:
w.second.get_executor().defer(std::move(f), alloc2);
try:
boost::asio::defer(w.second.get_executor(), std::move(f));
You will need to add #include <boost/asio/defer.hpp> for this.
Note: the above is completely untested.
You may want to ask for help regarding ASIO on its GitHub project (https://github.com/chriskohlhoff/asio/). Boost.ASIO is auto-generated from ASIO and has the same API sans namespaces and macro names.
Hi, Thanks for your answer, I somehow managed to fix it! :) Cheers, Thomas Goirand (zigo)
participants (2)
-
Andrey Semashev -
Thomas Goirand