# Question about VTK libpython linkage
**URL:** https://discourse.vtk.org/t/question-about-vtk-libpython-linkage/7736
**Category:** Support
**Created:** [January 29, 2022, 10:38pm UTC](https://discourse.vtk.org/t/question-about-vtk-libpython-linkage/7736 "2022-01-29T22:38:32Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@opoplawski](https://discourse.vtk.org/u/opoplawski)
#### Post date: [January 29, 2022, 10:38pm UTC](https://discourse.vtk.org/t/question-about-vtk-libpython-linkage/7736/1 "2022-01-29T22:38:32Z")
I’m looking into this bug filed against the Fedora VTK package: [1979611 – linking errors](https://bugzilla.redhat.com/show_bug.cgi?id=1979611)
It appears that at least some VTK libraries are not getting linked against libpython, but I don’t know why. I don’t believe we are doing anything particularly different than Ubuntu.
In particular, it seems like /usr/lib64/libvtkPythonInterpreter.so.9.1.0 should be linked as it reports undefined symbols like Py\_Finalize.
Full build log is here: [https://kojipkgs.fedoraproject.org//packages/vtk/9.1.0/2.fc36/data/logs/x86\_64/build.log](https://kojipkgs.fedoraproject.org//packages/vtk/9.1.0/2.fc36/data/logs/x86_64/build.log)
A relevant link line:
/usr/bin/g++ -fPIC -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D\_FORTIFY\_SOURCE=2 -Wp,-D\_GLIBCXX\_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D\_UNICODE -DHAVE\_UINTPTR\_T -g -Wl,-lc -Wl,-z,relro -Wl,–as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,–build-id=sha1 -shared -Wl,-soname,libvtkPythonInterpreter.so.1 -o lib64/libvtkPythonInterpreter.so.9.1.0 Utilities/PythonInterpreter/CMakeFiles/PythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/PythonInterpreter.dir/vtkPythonInterpreter.cxx.o -Wl,-rpath,/builddir/build/BUILD/VTK-9.1.0/build/lib64: lib64/libvtkCommonMisc.so.9.1.0 lib64/libvtkWrappingPythonCore3.10.so.9.1.0 lib64/libvtkCommonMath.so.9.1.0 lib64/libvtkkissfft.so.9.1.0 lib64/libvtkCommonCore.so.9.1.0 lib64/libvtksys.so.9.1.0 -ldl -Wl,-rpath-link,/builddir/build/BUILD/VTK-9.1.0/build/lib64
Another possibility is that the library linkage the person reports is correct - and that the library user is expected to load libpython directly.
Any help would be greatly appreciated.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [January 30, 2022, 1:14pm UTC](https://discourse.vtk.org/t/question-about-vtk-libpython-linkage/7736/2 "2022-01-30T13:14:18Z")
Distros can probabaly set `VTK_PYTHON_OPTIONAL_LINK=OFF`. This is done by default to allow the interpreter loading the `vtk` Python package to bring its own Python library (e.g., Anaconda, system, or whatever) provided the ABI and versions are compatible. This is set up so that only the executables link to libpython and the rest just assume the symbols are around by the time they’re loaded. Since distros usually pin to specific interpreter deployments, they can just say “VTK uses this libpython, deal with it”.
---
### Author:  [@opoplawski](https://discourse.vtk.org/u/opoplawski)
#### Post date: [June 25, 2022, 3:09am UTC](https://discourse.vtk.org/t/question-about-vtk-libpython-linkage/7736/3 "2022-06-25T03:09:55Z")
Somehow didn’t see this until now. Thanks, that looks like just what we needed.