Update bundled boost

[drwells]

From the developer meeting today - we should get this done significantly ahead of the release.

[bangerth]

Since I'm not have much luck getting this to work, it might be useful to do it in a more systematic way. To make this possible, here's my workflow:

git checkout master
git checkout -b boost-1.83
cd bundled/
cp -r boost-1.70.0/ boost-1.83.0
cd boost-1.83.0/include/
rm -r boost/
mv ~/Downloads/boost_1_83_0/boost .
cd ../libs/
cp ~/Downloads/boost_1_83_0/libs/iostreams/src/{bzip2.cpp,file_descriptor.cpp,gzip.cpp,mapped_file.cpp,zlib.cpp} iostreams/src/
cp ~/Downloads/boost_1_83_0/libs/serialization/src/* serialization/src/
cp ~/Downloads/boost_1_83_0/libs/system/src/error_code.cpp system/src/error_code.cpp 
cd ../..
emacs setup_bundled.cmake 
git rm -r boost-1.70.0/
git add boost-1.83.0/
git commit -a -m "Import BOOST 1.83."
git push boost-1.83
git push origin boost-1.83
cd ..
git cherry-pick 184d3028152ba33c39848576f5d9ec206fdf75b0 42bb6bd9e1553ec06a9068cda3d0bb963542852c
emacs doc/news/changes/major/20240210Bangerth
git commit --amend -a
git push origin boost-1.83

[bangerth]

I have finally figured out what the problem is. In BOOST's smart_ptr library, it is trying to figure out which low-level primitives can be used. This happens in boost/smart_ptr/detail/sp_counted_base.hpp, which does

[...]

#include <boost/smart_ptr/detail/sp_has_gcc_intrinsics.hpp>
#include <boost/smart_ptr/detail/sp_has_sync_intrinsics.hpp>
#include <boost/config.hpp>

#if defined( BOOST_SP_DISABLE_THREADS )
# include <boost/smart_ptr/detail/sp_counted_base_nt.hpp>

#elif defined( BOOST_SP_USE_STD_ATOMIC )
# include <boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp>

#elif defined( BOOST_SP_USE_SPINLOCK )
# include <boost/smart_ptr/detail/sp_counted_base_spin.hpp>

#elif defined( BOOST_SP_USE_PTHREADS )
# include <boost/smart_ptr/detail/sp_counted_base_pt.hpp>

#elif defined( BOOST_DISABLE_THREADS ) && !defined( BOOST_SP_ENABLE_THREADS ) && !defined( BOOST_DISABLE_WIN32 )
# include <boost/smart_ptr/detail/sp_counted_base_nt.hpp>

#elif defined( BOOST_SP_HAS_GCC_INTRINSICS )
# include <boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp>

[...]

In that very first #include, boost/smart_ptr/detail/sp_has_gcc_intrinsics.hpp, it does the following:

#if defined( __ATOMIC_RELAXED ) && defined( __ATOMIC_ACQUIRE ) && defined( __ATOMIC_RELEASE ) && defined( __ATOMIC_ACQ_REL ) 

# define BOOST_SP_HAS_GCC_INTRINSICS

#endif

Apparently the assumption is that only GCC defines these preprocessor variables __ATOMIC_* (they are not set anywhere in BOOST). For reasons unclear to me, in our CI infrastructure, the MSVC compiler appears to set those, and consequently BOOST_SP_HAS_GCC_INTRINSICS is defined and then things go downhill because we include the file that implements stuff via GCC intrinsics which, of course, the MSVC compiler does not understand.

What is confusing to me is that I cannot find a trace on the internet of anyone else who would have run into this problem. The code shown above was introduced in BOOST 1.74, as far as I can tell, which was released in August 2020 -- so enough time for others to run into this issue too.

In any case, a safe patch would be to add && !defined(_MSC_VER) to the feature check above, and that made everything work with the current BOOST dev sources in #16850. I'm now testing the same for BOOST 1.84 in #16621.

[bangerth]

A different (perhaps better?) approach would be to unconditionally define BOOST_SP_USE_STD_ATOMIC which does not rely on compiler intrinsics but instead on std::atomic and related standard features. I cannot find much about this flag online, though. I did see a mention that suggests that it is not always set because at the time when BOOST smart_ptr was developed, not all compilers had reliable atomics implemented. But that was a dozen or so years ago, and one would assume that a fully compliant compiler would no longer have problems with this.

But this perhaps a question for a separate PR.

[vdilecce]

A different (perhaps better?) approach would be to unconditionally define BOOST_SP_USE_STD_ATOMIC which does not rely on compiler intrinsics but instead on std::atomic and related standard features.

If that could avoid the custom patch (e969195) I think it would be a better approach, allowing for external Boost installations to be used without problems.

[bangerth]

We took care of this.