Library conflict when importing PySide6 from C++ embedded Python application
-
I'm converting an embedded Python application written in C++ from Qt5/PyQt5 to Qt6/PySide6 and I've found that the Qt6 libraries that pip installed for PySide6 are in conflict with the system Qt6 libraries.
When running from the C++ application, Python code that imports PySide6.QtWidgets results in an undefined symbol "Qt_6_PRIVATE_API". This symbol exists in the version of libQt6Widgets.so.6 installed by pip in /usr/local/lib64/python3.6/site-packages/PySide6/Qt/lib/libQt6Widgets.so.6, but it doesn't exist in /usr/lib64/libQt6Widgets.so.6. The latter has "Qt_6.7_PRIVATE_API". (This is a Rocky8 system)
The Python standalone interpreter can import PySide6.PyWidgets without a problem. The issue arises when the C++ application that the cmake build system told to load Qt libraries from /usr/lib64 needs the symbols from similarly-named libraries installed for PySide6.
Simply specifying the PySide6 library location with LD_LIBRARY_PATH results in the undefined symbol Qt_6.7_PRIVATE_API, of course.
I'm confused why I can't find any other posts that mention this problem. Am I going to have to build PySide6 locally to solve it?
Matt
-
@mlperini
My 2 cents. Only my assumptions.The pip install of PySide6 is intended for Python use and deliberately standalone/self-contained/isolated from whatever Qt6 you may or may nor have outside on the system. If you have an incompatible version out there it doesn't matter.
Conversely the non-Python world just sees what is out there in the system, nothing to do with the Python. So again if they're incompatible it doesn't matter.
This works fine for distinct applications. But I can imagine that if you want to mix Python and system/C++ in one process don't you need them to be the exact same version to avoid grief?