New platform linking/cmake issues

ParaView Support
1

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
./paraview/modules/vtkRemotingApplication.so.0.0
./vtkmodules/vtkAcceleratorsVTKmCore.so.0.0
./vtkmodules/vtkAcceleratorsVTKmDataModel.so.0.0
./vtkmodules/vtkAcceleratorsVTKmFilters.so.0.0
./vtkmodules/vtkChartsCore.so.0.0
./vtkmodules/vtkDomainsChemistry.so.0.0
…etc.

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):

  -DPARAVIEW_USE_PYTHON=YES
  -DVTK_WRAP_PYTHON=ON
  -DPARAVIEW_VERSIONED_INSTALL=OFF
  -DVTK_VERSIONED_INSTALL=OFF
  -DPARAVIEW_BUILD_WITH_KITS=YES

The VTK_VERSIONED_INSTALL=OFF didn’t help, and the PARAVIEW_VERSIONED_INSTALL=OFF is needed for OpenBSD.

Other build options:

-DCMAKE_BUILD_TYPE=Release

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?

2

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)

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

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      build.ninja         foo.c               libfoo.so.1.1
CMakeFiles          cmake_install.cmake libfoo.so

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!

4

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?

5

Other projects simply use other names. For example:

xmms2 has 2 python libraries: xmmsapi.so and xmmsvalue.so but about two dozen system libraries libxmms_xxx.so (and libxmms_xxx.so.x.y of course).

Gnu Radio names the python libraries _xxx_yy.so and the system libraries are libgnuradio-xxxx.so

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.

6

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.