New platform linking/cmake issues

I’m trying to get ParaView running on OpenBSD (64-bit, AMD/x86 CPU)

I’ve succeeded to get a build and install done as per OpenBSD typical ports process.

The issue is: python site-packages/paraview/modules and site-packages/vtkmodules have a mix of versioned so files (29 of those) and plain so files (119 of those):

$ find . -name ‘*.0.0’ |sort

But python only looks for files ending with .so not the .so.0.0. The cmake/ninja build step produces the so.0.0 files plus a softlink to the .so. But the installation cmake files omit the .so link or the file it points at.

I’ve tried this set of definitions (together):



Other build options:


Compiler: clang 10.0.1, llvm linker, cmake 3.19.1, ninja 1.10.2.
Paraview 5.9.0 downloaded tar.xz file, no git used.

My question is: what controls generating the .so.0.0 files for some of the python site-packages? And how to turn it off for all?

Hmm. That’s odd. I don’t think we set any information related to that in the CMake code.

What happens with this simple CMake project? Does this get a .0.0 suffix?

cmake_minimum_required(VERSION 3.12)
project(test-cmake-module-obsd C)

  CONTENT "int foo() { return 0; }\n")
add_library(foo MODULE "${CMAKE_CURRENT_BINARY_DIR}/foo.c")

No and yes! This helped me understand the issue – it is actually an OpenBSD-ism.

A simple cmake using (GNU) make or Ninja did not generate a versioned file, but this does:

rpi$ export LIBfoo_VERSION=1.1
rpi$ cmake -G Ninja  ..
rpi$ ninja
rpi$ ls
CMakeCache.txt         foo.c     
CMakeFiles          cmake_install.cmake

The reason this occurs is due to OpenBSD ports strategy: all ported packages (third-party software) that generates a so file has the version managed by the OpenBSD ports infrastructure, not the original third-party. This so all 11,000 ports can have consistent linking, especially in the face of minor version changes. The symbol LIBxxx_VERSION=n.n is the input to the compiling / building system identifying the version to use.

Paraview is unusal that it generates so files for the system library and same file names for the python site-package. OpenBSD porting scheme doesn’t distinguish. So I will have to undo the versioning for the site-packages directories. The OpenBSD-based versioning for the system libraries does work correctly (of course) so no change required there.

Thank you for your demo code; it helped a lot!

Hmm. I guess if you’re building the unversioned names, this could happen, though the /usr/lib ones would (should) have a lib prefix and the site-packages not. Out of curiosity, how does this work for other Python module-shipping projects?

Other projects simply use other names. For example:

xmms2 has 2 python libraries: and but about two dozen system libraries (and of course).

Gnu Radio names the python libraries and the system libraries are

And so on. None of the 67 ports on OpenBSD that provide both system shared lib(s) and python site-package shared lib(s) have name overlaps between the two.

I realize it would be a big ask to suggest changing the VTK/Paraview python lib names, so I won’t. Too much code would break. It is what it is.

Thanks again for your help.

Hmm. That’s still confusing to me because the Python libraries should be lacking the lib prefix all of the /usr/lib system libraries should have. But maybe that is “factored out” when determining the name in the linker? Anyways, it sounds like you have a solution. Thanks for the info.