SyneRBI / SyneRBI_VM

Virtual Machine with pre-installed SyneRBI software
http://www.ccpsynerbi.ac.uk
Apache License 2.0
3 stars 7 forks source link

upgrading boost will result in build failures #105

Closed evgueni-ovtchinnikov closed 4 years ago

evgueni-ovtchinnikov commented 5 years ago

update_VM.sh and make fail when building ISMRMRD with lots of error messages like this one:

undefined reference to `boost::unit_test::ut_detail::auto_test_unit_registrar::auto_test_unit_registrar(boost::unit_test::test_case*, boost::unit_test::decorator::collector&, unsigned long)'
KrisThielemans commented 5 years ago

Short version:

check if ~/devel/install/include/boost exists, if so remove it and any boost library in ~/devel/install/lib. If update_VM.sh still fails, make sure that you build with USE_SYSTEM_BOOST=ON.

Long version:

I can confirm that this happens with my VM 1.1.1. Possibly I played around with it as it'd be a mystery that we only see this now... I do notice that update_VM.sh will get SIRF-SuperBuild v1.1.1 (as it should, but somewhat amazing that it wasn't already there) and recompile stuff, but anyway.

This kind of thing happens when there are different boost versions used at linking vs compilation time. It appears that on my VM, I have the system boost (v1.58.0) and boost headers only in~/devel/install/include/boost` (v1.63.0). Removing the latter made this problem go away.

I suspect what happened is that at some point a USE_SYSTEM_BOOST=OFF build was used, which installed 1.63.0. I guess I must have removed the boost libraries afterwards (or possibly the boost installation was aborted).

KrisThielemans commented 5 years ago

It's worse than this.

As we now build with USE_SYSTEM_BOOST=ON, we have 2 boost versions on the VM. FindBoost will find "our" version for the include, and would find our version for the libraries if we're doing a fresh install. However, as we now have 2 versions of boost, we run into the same trouble as https://github.com/CCPPETMR/SIRF-SuperBuild/issues/165

KrisThielemans commented 5 years ago

Ugly fix: add the following somewhere in UPDATE.sh (but would need to test if there's an existing build already)

~/devel/buildVM/
make Boost
cd builds/
for package in SIRF ISMRMRD Gadgetron; do
   if [ -r $package/build/CMakeCache.txt ]; then
    cmake -U Boost\* -DBOOST_ROOT=~/devel/install/ $package/build
   fi
done
KrisThielemans commented 5 years ago

There's another twist in this tale. CMake auto-tracks dependencies on .h files, but excludes system files. So, changing the system boost files, and rebuilding actually doesn't recompile the files that use the system boost files. It's then going to link with the new system boost libraries, and there's the trouble.

Current only solution seems to make clean. aargh.

KrisThielemans commented 4 years ago

As far as I can see, the only thing here is that if an update installs a new boost version, then the make will fail. I'll rename the issue accordingly.

A "serious update" like this is hopeless anyway. We might be covering such a case already in our upgrade instructions ("if your VM is much older, then the best thing might be to start from scratch, or if you cannot do that, remove old build files using rm -rf ~/devel/buildVM/builds before doing the upgrade."). @evgueni-ovtchinnikov could you have a look at our instructions (could be on the wiki) and then close this?