# New platform linking/cmake issues
**URL:** https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464
**Category:** ParaView Support
**Tags:** python
**Created:** [February 14, 2021, 10:10pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464 "2021-02-14T22:10:31Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@bitminer](https://discourse.paraview.org/u/bitminer)
#### Post date: [February 14, 2021, 10:10pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/1 "2021-02-14T22:10:31Z")
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?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 15, 2021, 3:09pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/2 "2021-02-15T15:09:51Z")
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?
```auto
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")
```
---
### Author:  [@bitminer](https://discourse.paraview.org/u/bitminer)
#### Post date: [February 15, 2021, 4:50pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/3 "2021-02-15T16:50:25Z")
> [@ben.boeckel](#):
>
> ```auto
> 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")
>
> ```
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:
```auto
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!
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 15, 2021, 5:09pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/4 "2021-02-15T17:09:10Z")
> [@bitminer](#):
>
> Paraview is unusal that it generates so files for the system library and same file names for the python site-package.
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?
---
### Author:  [@bitminer](https://discourse.paraview.org/u/bitminer)
#### Post date: [February 16, 2021, 12:58am UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/5 "2021-02-16T00:58:22Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 16, 2021, 12:50pm UTC](https://discourse.paraview.org/t/new-platform-linking-cmake-issues/6464/6 "2021-02-16T12:50:04Z")
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.