When building the internal Python version of ParaView 5.11.0-RC1 an internal version of liblzma.so is built. When building boost for use with OpenVDB (-DENABLE_openvdb=ON), boost uses the system library instead of the version built by Python. This works if the versions are the same, but if they differ enough
for example if the system version is liblzma.so.5.2.2 while the internal version is liblzma.so.5.2.5 there will be an error such as in this case
Build_5.11.0-RC1_mesa/install/lib/libboost_iostreams.so.1.79.0: undefined reference to `lzma_stream_encoder_mt@XZ_5.1.2alpha'
Build_5.11.0-RC1_mesa/install/lib/libboost_iostreams.so.1.79.0: undefined reference to `lzma_cputhreads@XZ_5.2.2'
I have found a workaround to force liblzma.so to not be used by boost that works around this issue.
Change line 72 of the superbuild/projects/boost.common.cmake in the superbuild from
${boost_extra_arguments})
to
${boost_extra_arguments} -sNO_LZMA=1 -a )
This forces a rebuild of boost without including liblzma.so and addresses the issue.
A more elegant solution might be preferred, but at least this works.
It sounds like a race condition. Since boost.cmake doesn’t declare an lzma dependency, the auto-detect can differ from run-to-run. We should just force disable it. The solution looks fine to me.
I think there might be a better spot to disable liblzma as my solution forces a rebuild without liblzma, but it would be better to build it the first time without liblzma, instead of forcing a rebuild without liblzma. But, I could not find the way to implement that easily.
Well, if you can figure how to configure boost not to use liblzma in the first stage of compiling boost, that would be great.
I am under the impression that my change, will build boost with liblzma, and then rebuild it again without liblzma. (the -a flag forces the rebuild I think, but this rebuild is needed as by this point if the rebuild is not done, than liblzma is already being required and the change of -sNO_LZMA=1 is not effective without forcing the rebuild with the flag -a)
It would be better to configure boost not to use liblzma in the first place, but I don’t know where to do that. And yes I think it is related to the other issue you mentioned.
It would probably be best to fix both of these issues at once, as they are clearly related, it is just that for me, the issue is with liblzma and boost, at least for now.
I think that’s because you gave it to just the install step. b2 is weird and doesn’t remember anything, so adding it to boost_options which uses it for both should do it.