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.
