CentOS7: Update to boost 1.69
In running HERD dummy under valgrind, on CentOS7 I found uninitialised value errors like the following:
==8== by 0x4EC027A: std::_Function_handler<herd::app::Server::ResponseSpec (herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&), herd::app::Server::ResponseSpec (herd::app::Server::*)(std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&)>::_M_invoke(std::_Any_data const&, herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EBB7B7: herd::app::Server::invokePutCallback(herd::app::Server&, std::function<herd::app::Server::ResponseSpec (herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&)> const&, httplib::Request const&, httplib::Response&, bool) (in /usr/lib64/libherd_app.so)
==8== by 0x4EE346A: ??? (in /usr/lib64/libherd_app.so)
==8== by 0x4EF1D27: httplib::Server::routing(httplib::Request&, httplib::Response&, httplib::Stream&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EF2D21: httplib::Server::process_request(httplib::Stream&, bool, bool&, std::function<void (httplib::Request&)> const&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EF38CD: httplib::Server::process_and_close_socket(int) (in /usr/lib64/libherd_app.so)
==8== by 0x4EC271A: std::thread::_State_impl<std::thread::_Invoker<std::tuple<httplib::ThreadPool::worker> > >::_M_run() (in /usr/lib64/libherd_app.so)
==8== by 0x5B83D4E: ??? (in /usr/lib64/libswatch_action.so)
==8== by 0x7E6DEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==8== by 0x7475B0C: clone (in /usr/lib64/libc-2.17.so)
==8== Uninitialised value was created by a heap allocation
==8== at 0x4C2A593: operator new(unsigned long) (vg_replace_malloc.c:344)
==8== by 0x4ED4566: boost::uuids::detail::seed_rng::sha1_random_digest_() (in /usr/lib64/libherd_app.so)
==8== by 0x4EB4C5A: herd::app::Server::Lease::Lease(std::string const&, float) (in /usr/lib64/libherd_app.so)
==8== by 0x4EB5327: herd::app::Server::executeObtainLease(std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EC027A: std::_Function_handler<herd::app::Server::ResponseSpec (herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&), herd::app::Server::ResponseSpec (herd::app::Server::*)(std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&)>::_M_invoke(std::_Any_data const&, herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EBB7B7: herd::app::Server::invokePutCallback(herd::app::Server&, std::function<herd::app::Server::ResponseSpec (herd::app::Server&, std::vector<std::string, std::allocator<std::string> > const&, Json::Value const&)> const&, httplib::Request const&, httplib::Response&, bool) (in /usr/lib64/libherd_app.so)
==8== by 0x4EE346A: ??? (in /usr/lib64/libherd_app.so)
==8== by 0x4EF1D27: httplib::Server::routing(httplib::Request&, httplib::Response&, httplib::Stream&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EF2D21: httplib::Server::process_request(httplib::Stream&, bool, bool&, std::function<void (httplib::Request&)> const&) (in /usr/lib64/libherd_app.so)
==8== by 0x4EF38CD: httplib::Server::process_and_close_socket(int) (in /usr/lib64/libherd_app.so)
==8== by 0x4EC271A: std::thread::_State_impl<std::thread::_Invoker<std::tuple<httplib::ThreadPool::worker> > >::_M_run() (in /usr/lib64/libherd_app.so)
==8== by 0x5B83D4E: ??? (in /usr/lib64/libswatch_action.so)
==8== by 0x7E6DEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==8== by 0x7475B0C: clone (in /usr/lib64/libc-2.17.so)
By contrast, valgrind doesn't report any errors for HERD dummy on Alma 8 & 9.
HERD currently uses boost version 1.53 on CentOS7, which is about 10 years old. I think this issue is fixed in newer boost versions. Why update to boost v1.69 specifically? It's included in the EPEL repos, and is only 5 years old.