"Clean" installation of ParaView 5.10 with superbuild

ParaView Support
1

Hi,

I am really sorry for starting another thread on this…

After some successful PV5.9 I decided to spend some time to tidy up my environment and upgrade to 5.10 as I want to explore the topology toolkit. I have automated my ParaView+OSMESA+Catalyst build script entirely and regressing to 5.9.1 works.

With 5.10 I get several problems:

  • Some headers of conduit appear to be missing in install/include/paraview-5.10/catalyst, which trips my adaptor compilation.
  • Python library of superbuild does not appear to be linked. I need to force it with LD_PRELOAD to avoid missing symbols. This is something that is definitely caused by environment, but I am just surprised that with 5.9.1 and the same build/Lmod script I do not encounter this problem.
  • libconduit_catalyst.so is nowhere to be found in the install/ tree and I get missing symbols from a compiled adaptor.

Also, I have read here that I should not be using make install with superbuild, so I point all of my environment to install/ directory within the superbuild build directory. I am assuming that this is the minimal setup. Unfortunately, I maintain my own Lmod module file so I just want to know this to reduce the probability of making another mistake.

Would appreciate any hints on how to fix this, as I am looking to share my installation with a wider audience and would like to have robust installation.

2

@ben.boeckel

3

We only install the C API. However, if it is the blueprint_exports.h header, that is indeed missing. You can manually copy it from superbuild/paraview/build in the meantime (it is fixed for 5.11; not sure if 5.10.1 has it or not).

Python modules should not link libpython.so and so they do not. The symbols are meant to be brought in by the loading interpreter (which is what selects the ilbpython that will be used).

This library doesn’t sound familiar to me. What wants it?

4

Thanks!

@ben.boeckel, I was slightly incorrect about Conduit, it’s a .a rather .so. It’s an HPC data exchange module, that @utkarsh.ayachit used for Catalyst2 API back in PV 5.9.

Comparing my 5.9.1 build and 5.10.0:

  • in 5.9.1: I have install/lib/libconduit_catalyst2.0.a and libcatalyst.so,
  • in 5.10.0 I only have libcatalyst.so.

I will recheck this Python issue later today and report here.

5

That static library shouldn’t be installed (as it is not part of the API that Catalyst provides), so that makes sense.

6

@ben.boeckel, I am sorry - I had to prioritise another project in March, but now I am back to it and I still cannot get it to work.

I do not understand why the conduit library should not be installed. Can you explain? There are two libraries here: conduit_catalyst2 and catalyst. In 5.9 I find static version of the former and dynamic of the latter. In 5.10 I cannot find conduit at all. Do you mean to say that I need to build conduit separately? It feels against the superbuild concept to me, but please let me know what you think.

I don’t think conduit API was subsumed into Catalyst because when I build my adapter (in C++) it fails with missing lnks to conduit function calls.

7

Catalyst does not install a generic Conduit library. Instead, it only offers a C API to the Conduit in use (and then rewraps that with some C++ code for more convenient usage there). Basically, we do not want to endanger Catalyst’s ABI compatibility by exporting the Conduit API/ABI directly.