would this require an upgrade in C++ STL?
If not, i think we should just upgrade to C++14 or something, because that replaces a lot of the things that boost currently has

just upgrade to C++14

There is ongoing discussion on when the right time is to bump c++. It seems the plan is to skip c++14 and go straight to c++17, but it'll probably be a while: #13356 (comment) and #16684

Getting rid of Boost altogether is not likely to happen anytime soon, see e.g. #8670 (2016!)

As this doesn't bump the minimum required version of boost, just the one used in depends, it's ok with me.

For reference:

https://packages.debian.org/source/sid/boost-defaults
https://apps.fedoraproject.org/packages/boost/overview/
https://packages.ubuntu.com/eoan/libboost-all-dev
https://www.archlinux.org/packages/extra/x86_64/boost/
https://packages.gentoo.org/packages/dev-libs/boost

Boost 1.71 or newer is useful for #15382.

Release notes for Boost 1.71.0 do not mention any change in Process library (required in #15382) at all. Did I miss something?

It fixes an unused variable, which is needed to pass Travis these days.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• Multiprocess build support #18677 (Multiprocess build support by ryanofsky)
• Multiprocess bitcoin #10102 ([experimental] Multiprocess bitcoin by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Concept ACK.

Given that the feature freeze is March 15th and there's still no new Boost release, 1.72 it is...

Should I update the various boost related autoconf files too (haven't checked if there's new ones)?

Concept ~0.

On the one hand, I think bumping a major dependency two versions to fix an unused variable in a module we don't even use, "is useful for #15382. ", is a bit ridiculous. Especially when, if required, it could be fixed quite easily in preprocessing. i.e:

diff --git a/depends/packages/boost.mk b/depends/packages/boost.mk
index cd0e70fb1..01b1f9c52 100644
--- a/depends/packages/boost.mk
+++ b/depends/packages/boost.mk
@@ -29,6 +29,7 @@ $(package)_cxxflags_android=-fPIC
 endef
 
 define $(package)_preprocess_cmds
+  sed -i.old "s/int ret_sig = 0;//" boost/process/detail/posix/wait_group.hpp && \
   echo "using $($(package)_toolset_$(host_os)) : : $($(package)_cxx) : <cxxflags>\"$($(package)_cxxflags) $($(package)_cppflags)\" <linkflags>\"$($(package)_ldflags)\" <archiver>\"$($(package)_archiver_$(host_os))\" <striper>\"$(host_STRIP)\"  <ranlib>\"$(host_RANLIB)\" <rc>\"$(host_WINDRES)\" : ;" > user-config.jam
 endef

On the other, we seem to be be semi-regularly bumping Boost in depends, so maybe we should prior to the 0.20.0 release. I assume you've tested this everywhere. Looks like there are a bunch of filesystem changes in 1.72.0. Do we need to do anything in regards to:

On Windows, use Boost.WinAPI to select the target Windows version.

?

Should I update the various boost related autoconf files too

If there's no applicable bug fixes to any of them, probably not. If there are, and you do update them, please test them across all operating systems and hardware we support so that we don't end up with another issue like #17010.

I don't think it's necessary to include this in 0.20. Let me word it differently: if we want to bump Boost before the next release, then let's bump to 1.72. But otherwise I'll just leave this PR open until #15382 comes closer (with your patch as an alternative).

I've been testing that PR and stuff built on top of it for a while and haven't seen any Boost issues, but I haven't specifically looked for them. Notably I haven't tested on Windows.

Focal ships with 1.71, btw

I switched to using @fanquake's workaround in my own PR. Given that Focal, the new LTS version of Ubuntu, ships with 1.71, it seems premature to bump to 1.72 unless there's a better reason.