[Debian-med-packaging] Bug#835416: imagevis3d: FTBFS: singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

[Tom Fogal]

Hi, thanks for looking into this.

On 09/20/2016 02:45 AM, peter green wrote:
>> 1. It's failing in the doc/genlua stuff, which is an internal tool meant
>> to generate documentation that is currently unfinished.  Arguably it
>> should be removed from source releases anyway.  So a simple fix is for
>> debian to just remove this directory from SUBDIRS in TuvokSubdirs.pro.
>
> I don't see a file called TuvokSubdirs.pro , I guess you mean 
> Tuvok/Tuvok.pro ?

Ahh, this must just be an older version, mea culpa.  Yeah, IIRC it would
be there.

> Anyway I removed doc/genlua from SUBDIRS in Tuvok/Tuvok.pro and tried a 
> build in raspbian stretch.
> 
> Unfortunately it failed with
> 
> g++ -fopenmp -Wl,-z,relro -o ../Build/ImageVis3D 
[snip]
> ../Tuvok/Build/libTuvok.a(SysTools.o): In function 
> `SysTools::GetTempDirectory(std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> >&)':
> ./Tuvok/Basics/SysTools.cpp:1060: warning: the use of `tmpnam' is 
> dangerous, better use `mkstemp'
> ../Build/objects/ImageVis3D_WindowHandling.o: In function 
> `boost::serialization::singleton<tuvok::MasterController>::get_mutable_instance()':
> /usr/include/boost/serialization/singleton.hpp:131: undefined reference 
> to `boost::serialization::singleton_module::is_locked()'

Yes, this is the same issue that was causing 'genlua' to fail; looks
like simply removing that code wasn't a great workaround.  Sorry.

I dug a bit deeper, by downloading boost 1.61 and verifying that,
indeed, the singleton.hpp included there is NOT a header-only library,
yet the one included in Tuvok's 3rdParty directory IS a header-only library.

Looking closer at the build log, I note that it is missing many of the
-I options that upstream has.  Notably in this case:
-IIO/3rdParty/boost.  This in turn causes it to use the system copy of
boost, which has changed behavior to require a new link option.

I can think of a number of solutions:

  * build-dep require a similar version of boost on the system.  I
    can confirm 1.58 is fine.  Note that the runtime is irrelevant
    since IV3D restricts itself to header-only parts of boost.

  * don't hack out the -I flags from upstream so that IV3D uses its
    internal copy of boost.

  * edit the .pro files to force this to link against
    libboost_serialization.so.