I found a conflict between the system versions of liblzma and the internal version built by python for ParaView 5.11.0-RC1


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} -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.


Joe Hennessey


I have found that this issue is still present in 5.11.0-RC2 as well.

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.



Why would your fix not be the same thing as disabling lzma on the first build?

LZMA is just one problem. See this MR:



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.


I have added these lines

list(APPEND boost_options

after line 14 of superbuild/projects/boost.common.cmake

and tested that it no longer does an unnecessary rebuild,
I have also tested that it works with the 5.11.0 superbuild



It looks like the superbuild bump missed 5.11. I’ll update there so that any 5.11.1 has it.