Ooph, I worked on <https://github.com/osquery/osqu...
# corek
Konstantin Sykulev
07/08/2025, 12:50 PMOoph, I worked on https://github.com/osquery/osquery/issues/8593 [Build broken with XCode 16.3] boost upgrade.
https://github.com/osquery/osquery/pull/8641
Everything was going mostly well until about 91% on linux.
It appears that the toolchain we are using is not compatible with boost 1.88 / C++20 standards
Konstantin Sykulev
07/08/2025, 12:50 PM Copy code
In file included from /usr/local/osquery-toolchain/usr/bin/../include/c++/v1/unordered_map:409:
/usr/local/osquery-toolchain/usr/bin/../include/c++/v1/__hash_table:2147:23: error: cannot initialize object parameter of type 'std::__1::__hash_node_base<std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *> *>' with an expression of type 'std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *>'
= __h.get()->__ptr();
^~~~~~~~~
/usr/local/osquery-toolchain/usr/bin/../include/c++/v1/__hash_table:2154:16: error: static_cast from 'std::__1::unique_ptr<std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *>, std::__1::__hash_node_destructor<std::__1::allocator<std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *> > > >::pointer' (aka 'std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *> *') to 'std::__1::__hash_table<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, std::__1::__unordered_map_hasher<int, std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, std::__1::hash<int>, true>, std::__1::__unordered_map_equal<int, std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, std::__1::equal_to<int>, true>, std::__1::allocator<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor> > >::__next_pointer' (aka 'std::__1::__hash_node_base<std::__1::__hash_node<std::__1::__hash_value_type<int, osquery::ProcessContext::FileDescriptor>, void *> *> *'), which are not related by inheritance, is not allowed
__nd = static_cast<__next_pointer>(__h.release());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14 errors generated.
make[2]: *** [osquery/events/CMakeFiles/osquery_events.dir/build.make:230: osquery/events/CMakeFiles/osquery_events.dir/linux/bpf/processcontextfactory.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 91%] Building CXX object plugins/config/parsers/CMakeFiles/plugins_config_parsers.dir/events_parser.cpp.o
make[1]: *** [CMakeFiles/Makefile2:17025: osquery/events/CMakeFiles/osquery_events.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....Konstantin Sykulev
07/08/2025, 12:51 PMz
zwass
07/09/2025, 4:05 PM
Hmm, I thought we were already using c++20...? @alessandrogario @Stefano Bonicatti any ideas?
k
Konstantin Sykulev
07/09/2025, 6:29 PMYeah not quite sure I really understand what the issue is. However, I did create an issue in fleet to deal with it. https://github.com/fleetdm/fleet/issues/30639
Might be something easy, might be something more involved. But I ran out of my timebox on the boost upgrade.
Mac ✅ compiling
linux ❌ not compiling
windows ❓ unsure
Lot's of warnings and a fair number of test failures popped up after compiling on mac.
So there is a fair bit of work to be done
s
Stefano Bonicatti
07/09/2025, 6:30 PMWe are not compiling with C++20, but 17: https://github.com/osquery/osquery/blob/600495f52a9ac7080f0df805f70460932e161093/cmake/flags.cmake#L26
👀 1
Stefano Bonicatti
07/09/2025, 6:41 PMThe Linux toolchain is unfortunately a bit old but clang 9.0.1 should've some support to C++20 (https://en.cppreference.com/w/cpp/compiler_support/20)
I'm not sure however if it's enough.
The upstream osquery-toolchain repo has changes in its build script to build with LLVM/Clang 11 done a while ago but we never then built and distributed an official release to use with osquery.
I'm also not sure if going to the 11 is enough.
Technically I have been working in the past on updating to 14, but that would create an issue with ebpfpub which uses LLVM internals that have been changed.
I had some WIP to update it but still need work, but time is sorely lacking.
Although I'm finding now something that I may have missed back then, which is that with LLVM 14 it might still be possible to make it present the old API interface which would permit to not have to update ebpfpub yet.
k
Konstantin Sykulev
07/09/2025, 7:18 PMThis is good context. Thanks @Stefano Bonicatti
8 Views