search

leycec / raiagent

Third-party Gentoo overlay. Ride the Lagrangian point between awesomeness and volatile compounds.
31 stars 14 forks source link

pyside2 cmake target file is only compatible with python3 #74

Closed efferre79 closed 4 years ago

efferre79 commented 4 years ago

I am using your ebuilds to install pyside2 and shiboken2, thanks for your effort.

When using python2 to build a package which uses pyside2 I get a reference to /usr/lib64/libpyside2-python3.6.so.5.12.5 which is of course wrong. After investigating a little bit I have noticed /usr/lib64/cmake/PySide2-5.12.5/PySide2Targets-gentoo.cmake which references always to that library. In comparison /usr/lib64/cmake/Shiboken2-5.12.5/Shiboken2Targets-gentoo.cmake seems to use the PYTHON_CONFIG_SUFFIX variable to select the python version.

efferre79 commented 4 years ago

actually it seems that also in /usr/lib64/cmake/Shiboken2-5.12.5/Shiboken2Targets-gentoo.cmake there is a problem with the Shiboken2::shiboken2 binary target which always points to /usr/bin/shiboken2-python3.6 while the library target Shiboken2::libshiboken looks fine

efferre79 commented 4 years ago

On my system I have the following configuration, PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7 -python3_8" used to build pyside2 and shiboken2

leycec commented 4 years ago

The linkage pain continues. I appreciate the tortuous writeup. You are, of course, absolutely right about absolutely everything.

what we do now, bro

If I'm reading your exhaustive analysis correctly, we'll need to patch:

Well, that's certainly doable. Three alcoholic cheers for that. :clinking_glasses:

why this still broke, bro

Allow me to shamefully explain why this is still painfully broken. First and foremost, upstream doesn't officially support our use case under Gentoo. The Qt Company only ever intended Shiboken2 and PySide2 to be statically built against a single Python version. We, of course, need to dynamically build both against arbitrarily many Python versions. Technically, this is feasible with extreme sed munging. Obviously, we're not there yet. Insert </megasigh> here.

Secondly, we have no idea how to test this functionality. Our PySide2-based multiphysics biology simulator only dynamically imports from the high-level PySide2 package at Python runtime rather than statically linking against lower-level shared library objects at C++ compilation time. Since this is our main test case, the /usr/lib64/lib{shiboken2,pyside2}-*.so*, /usr/lib64/pkgconfig/{shiboken2,pyside2}*.pc, and /usr/lib64/cmake/{Shiboken2,PySide2}/*.cmake files are all untested. Don't crucify me.

when this gonna end, bro

So, thanks a heap overflow for testing this for us all! Brave bleeding-edge victims volunteers are always more than welcome.

We'll get this patched up for you in a jiffy. Jiffy lube not included.

leycec commented 4 years ago

Bam! The Shiboken2 and PySide2 ebuilds have been bumped up to shiboken2-5.12.5-r2 and pyside2-5.12.5-r2. If you could manually test both on your end and verify that they resolve your project's issues and bring balance back to the Qt Force, I will happily cry man tears of salty joy... yet again. :joy:

efferre79 commented 4 years ago

I confirm that your latest ebuild fixes my problem, thanks!