# "Clean" installation of ParaView 5.10 with superbuild
**URL:** https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043
**Category:** ParaView Support
**Tags:** python
**Created:** [February 23, 2022, 10:43am UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043 "2022-02-23T10:43:07Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@robertsawko](https://discourse.paraview.org/u/robertsawko)
#### Post date: [February 23, 2022, 10:43am UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/1 "2022-02-23T10:43:07Z")
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](https://discourse.paraview.org/t/compiling-headless-paraview-with-osmesa/8377/13) 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](https://discourse.paraview.org/t/superbuild-install-target-fails-with-v5-10/8942/2) 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.
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [February 24, 2022, 12:03am UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/2 "2022-02-24T00:03:35Z")
@ben.boeckel
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 25, 2022, 2:06pm UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/3 "2022-02-25T14:06:14Z")
> [@robertsawko](#):
>
> Some headers of conduit appear to be missing in `install/include/paraview-5.10/catalyst`, which trips my adaptor compilation.
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).
> [@robertsawko](#):
>
> 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.
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).
> [@robertsawko](#):
>
> `libconduit_catalyst.so` is nowhere to be found in the `install/` tree and I get missing symbols from a compiled adaptor.
This library doesn’t sound familiar to me. What wants it?
---
### Author:  [@robertsawko](https://discourse.paraview.org/u/robertsawko)
#### Post date: [February 26, 2022, 9:50am UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/4 "2022-02-26T09:50:19Z")
Thanks!
@ben.boeckel, I was slightly incorrect about [Conduit](https://llnl-conduit.readthedocs.io/en/stable/index.html), it’s a `.a` rather `.so`. It’s an HPC data exchange module, that @utkarsh.ayachit used for [Catalyst2 API](https://www.kitware.com/catalyst-improvements-in-paraview-5-9/) 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.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 26, 2022, 2:10pm UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/5 "2022-02-26T14:10:13Z")
That static library shouldn’t be installed (as it is not part of the API that Catalyst provides), so that makes sense.
---
### Author:  [@robertsawko](https://discourse.paraview.org/u/robertsawko)
#### Post date: [April 8, 2022, 3:25pm UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/6 "2022-04-08T15:25:26Z")
@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.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 19, 2022, 10:41am UTC](https://discourse.paraview.org/t/clean-installation-of-paraview-5-10-with-superbuild/9043/7 "2022-05-19T10:41:53Z")
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.