Build redistributable ParaView (SDK) using ParaViewPluginBuilder

ParaView Support
1

Hello,

I recently got my question answered on how to build a plugin that can be loaded into the official ParaView binary (thanks!). Apparently, there is this nice repository called ParaViewPluginBuilder that sets up the same build environment used for creating the official releases through a Docker container.

Now I was trying to create a redistributable ParaView SDK using the same environment. In order to test if that is possible I first tried to run ParaView (built inside the Docker container) on my host machine (Ubuntu 16.04). This resulted in some linking issues:

$ ldd ./bin/paraview | grep "not found"
	libGLX.so.0 => not found
	libOpenGL.so.0 => not found
	libQt5Help.so.5 => not found

I found that a couple of ParaView libraries depend on libGLX.so and libOpenGL.so, which are not available on my host machine (Ubuntu 16.04), but were available on the Docker machine. Inspecting the same ParaView libraries that are on Kitware’s download page (with ldd), I find that libGLX.so and libOpenGL.so are not linked. An example of such a library is libvtkRenderingOpenGL2-pv5.8.so. This library from the official release relies on libGL.so and libGLU.so instead.

So my question is: how were the official binaries built? It seems not by using the Docker container from ParaViewPluginBuilder. Is there another Docker container for the actual ParaView releases?

Best,
Ahmad

2

I first tried to run ParaView (built inside the Docker container) on my host machine (Ubuntu 16.04).

Unsupported. If you want to run paraview, just download the release.

how were the official binaries built?

Using a docker setup similar to paraview-plugin-builder, and then using the packaging tools that make sure all libraries are available in the package.

Having access to this setup will not help you.

Build redistributable ParaView (SDK) using ParaViewPluginBuilder

Not supported, and not redistributable anyway. If it was, we would already be providing it for people to download.

@ben.boeckel : is this correct ?

3

Thanks for your reply.

Not supported, and not redistributable anyway. If it was, we would already be providing it for people to download.

Yes, I am aware that Kitware is not providing this. In previous ParaView versions (<= 5.6) we used to distribute ParaView SDK (ParaView superbuild with -Dparaviewsdk=ON) for Ubuntu (16.04, 18.04) and CentOS (7) users by building them respectively in Ubuntu (16.04, 18.04) and CentOS (7) Docker containers. We need the SDK specifically because the library that we develop uses a ParaView in-situ C++ pipeline to generate visualization output.

Do you know the reason for why the flag paraviewsdk breaks the redistribution? AFAIK, the flag copies the headers and CMake files for other software to build against ParaView.

I guess for now we will have to continue distributing distro-specific SDKs.

4

ABI issues, but I defer, once again, to @ben.boeckel.

5

I believe the OpenGL thing is due to GLVND differences on the build and target platform. I think we prefer GLVND, but if we’re linking libGL.so, that seems to not be the case… I wonder if the Mesa build is what makes this switch happen?

As for the SDK, I believe its main use case has been supplanted by Spack, so that it has lagged behind isn’t that much of a surprise (it’s main use case was for deployment to HPC machines, not redistributable SDKs).

The reason we can’t distribute a general SDK is because the dev environment relies on whatever magic Red Hat does to get devtoolset to work with newer compilers and still working with older libstdc++ releases. That environment, AFAIK, is not available on Ubuntu, so the best we would be able to do is something like the Docker image provided. Once we’re on gitlab-ci, the full build process for release binaries should be documented in the main repository (Linux is there now, but I don’t know if we’re trusting it for release-ready binaries yet).

1 Like