boost linking problems on Travis OSX

[KrisThielemans]

We have linking errors now related to boost::thread. Excerpt from the CIL PR (but there's nothing specific to CIL here), which is a case with USE_SYSTEM_Boost=ON:

[ 81%] Linking CXX shared module _pygadgetron.so

Undefined symbols for architecture x86_64:
  "boost::detail::thread_data_base::~thread_data_base()", referenced from:
      boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, sirf::GadgetronClientConnector>, boost::_bi::list1<boost::_bi::value<sirf::GadgetronClientConnector*> > > >::~thread_data() in libcgadgetron.a(gadgetron_client.cpp.o)

      boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, sirf::GadgetronClientConnector>, boost::_bi::list1<boost::_bi::value<sirf::GadgetronClientConnector*> > > >::~thread_data() in libcgadgetron.a(gadgetron_client.cpp.o)
  "boost::thread::join_noexcept()", referenced from:
      boost::thread::join() in libcgadgetron.a(cgadgetron.cpp.o)
      boost::thread::join() in libcgadgetron.a(gadgetron_x.cpp.o)

Looking through the build log I see in many places things like

/usr/local/lib/cmake/boost_program_options-1.71.0/boost_program_options-config.cmake:43 (include)
  /usr/local/lib/cmake/Boost-1.71.0/BoostConfig.cmake:117 (find_package)
  /usr/local/lib/cmake/Boost-1.71.0/BoostConfig.cmake:182 (boost_find_component)
  /usr/local/Cellar/cmake/3.11.4/share/cmake/Modules/FindBoost.cmake:261 (find_package)
  utilities/CMakeLists.txt:24 (find_package)
-- Boost 1.43 found.

which seems quite suspicious as there's 2 different versions of Boost here. (This one was for ISMRMRD). So my guess is this is a version conflict.

I did some further digging...

Brew is doing

==> Downloading https://homebrew.bintray.com/bottles/boost-1.71.0.high_sierra.bottle.tar.gz

The Superbuild says

- Boost 1.66.0 found.
-- USING the system Boost, using BOOST_LIBRARY_DIR=

Note that it reported 1.66 here!

The SIRF CMakeCache.txt (printed at the end of the Travis script) has

BOOST_INCLUDEDIR:UNINITIALIZED=/include/
...
BOOST_ROOT:PATH=
Boost_DIR:PATH=/usr/local/lib/cmake/Boost-1.71.0
...
boost_thread_DIR:PATH=/usr/local/lib/cmake/boost_thread-1.71.0
...

This indicates that Boost 1.71.0 is installed with a config file, which is found by CMake (hence CMake sets Boost_DIR). That should in principle set the include path for the compiler appropriate. However, it can still fail if there's another Boost version in the include path set by other things.

Possible work-arounds:

• it might disappear if we'd force CMake to ignore Boost's config.cmake (could be done by setting -DBoost_NO_BOOST_CMAKE=ON) as then we might have BOOST_ROOT or BOOST_INCLUDEDIR, and the correct version of boost might appear first in the compiler path, but that's a loosing strategy.

• upgrade CMake. it is 3.11.4 on Travis while 3.15 is available. It might magically fix it (but I don't think so).

• replace boost::thread with std::thread.

The latter is my vastly preferred option. Whatever tricks we play, this is going to come and bite us again and again. See also #241.

I hope this might be a rather easy exercise as Boost::thread is since a while nearly completely C++11 compatible

Of course, there might be other version conflicts still hitting us, for instance with ISMRMRD or Gadgetron, but let's hope not...

[KrisThielemans]

PR #430 resolves most of these. However, there's one (?) remaining, from the log

[ 85%] Linking CXX executable sirf_crop_image

Undefined symbols for architecture x86_64:

  "boost::filesystem::detail::create_directory(boost::filesystem::path const&, boost::system::error_code*)", referenced from:
      sirf::NiftiImageData<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) const in libReg.a(NiftiImageData.cpp.o)
      sirf::AffineTransformation<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in libReg.a(AffineTransformation.cpp.o)

  "boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)", referenced from:
      sirf::NiftiImageData<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) const in libReg.a(NiftiImageData.cpp.o)
      sirf::AffineTransformation<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in libReg.a(AffineTransformation.cpp.o)
  "boost::filesystem::path::parent_path() const", referenced from:
      sirf::NiftiImageData<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) const in libReg.a(NiftiImageData.cpp.o)
      sirf::AffineTransformation<float>::write(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in libReg.a(AffineTransformation.cpp.o)
ld: symbol(s) not found for architecture x86_64

My guess is that this is related to @rijobro's removal of linking to the boost libs in SIRFreg (58f4f55). #241 (comment). (I never understood why that would have worked anyway). We could re-insert it (e.g. on OSX only) but might then be caught by the same version conflicts as above. sigh.

[KrisThielemans]

As #430 seems to work, I think removing boost::filesystem dependency (and hence boost::sytem) is the way to go, especially as recent Gadgetron hardly depends on boost at all.

@rijobro it seems you use boost::filesystem in very few places, and very few functions of it. A few options to remove it:

• check if std::filesystem exists in CMake, and if it does, use that. Add CMAKE_CXX_STANDARD=14 for OSX and hope for the best.
• replace it with our own functions for now. This might be very little work as there are things that help:
  • @evgueni-ovtchinnikov already has file_exists here
  • some other stuff that you might need is in @NikEfth's FilePath which you could copy a few lines from a new SIRF/common file (with appropriate copyright)

[KrisThielemans]

This is no longer a pressing issue, although the general difficulties still remain. Pending #430 I guess, so I'll close this issue.