icfwm at gmx.net
icfwm at gmx.net
Sun Mar 29 21:28:10 CEST 2020
thanks for reply. I also went the manylinux2014 path now and got the
extension to be manylinux2014 compatible except for the QT dependencies
(which are resolved by PySide2 and shiboken2 in the end). One potential
issue is llvm, which I currently bypass by using an up to date linux to
generate the binding cpp/h files. It looks like PySide2 might already be
compatible to manylinux2014 which is CentOS 7 based (but that's just a
guess from unexperienced me with these matters).
While digging into this I also learned about this PEP which has been
accepted for the future (following manylinux2014):
On 29.03.20 19:47, Cristián Maureira-Fredes wrote:
> Hello Christoph,
> On 3/27/20 7:06 PM, icfwm at gmx.net wrote:
>> I'm seeing you are tagging the linux binary release with the manylinux1
>> tag. However, when importing PySide2 on the manylinux1 docker container,
>> it fails saying GLIBCXX_3.4.18 not found. So I assume you are
>> pragmatically advertising the manylinux1 tag to be able to upload binary
>> releases to pypi. I appreciate this - having to build PySide2 before
>> installing would limit the usability a lot.
> You are right, it's not 100% a manylinux1,
> you can find some comments about it here:
>> However, this imposes a problem when trying to release python extensions
>> depending on the PySide2 extension. May I ask, which system you are
>> actually using to build PySide2 - I assume it is the same system which
>> is used to build the qt libraries itself?
> I totally understand,
> and hopefully we can work on this, even adopt a new scheme like
> manylinux2014, but at the moment it's still in our backlog.
> We are generating the wheels in Qt's CI, and particularly on RHEL7,
> which is the minimum requirement to build Qt.
> If you have more questions,
> let us know.
More information about the PySide