<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 7, 2022, at 4:39 PM, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com" class="">phil@riverbankcomputing.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 07/08/2022 16:34, Thomas Watson wrote:<br class=""><blockquote type="cite" class="">On Aug 7, 2022, at 4:36 AM, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com" class="">phil@riverbankcomputing.com</a>> wrote:<br class=""><blockquote type="cite" class="">The minimum_glibc_version should determine what tag is used. PyQt-builder sets this to v2.17 for PyQt5. 'manylinux1' suggests that the version is set to something less than v2.5 or not set at all.<br class="">What is the version set to?<br class=""></blockquote>I verified on my aarch64 machine that the minimum_glibc_version ends<br class="">up set to v2.5. I see on line 116 of "pyqtbuild/builder.py" in the<br class="">PyQt-builder-1.13.0 sdist the clause that I believe intends to set the<br class="">default minimum_glibc_version for PyQt5 to v2.17 like you say it<br class="">should be. However, by this time, project.minimum_glibc_version is<br class="">already set to v2.5.<br class="">I did some digging and found that line 468 of "sipbuild/project.py" in<br class="">the sip-6.6.2 sdist sets the minimum_glibc_version to v2.5, so perhaps<br class="">that is where PyQt-builder is getting it? The official release wheels<br class="">( <a href="https://pypi.org/project/PyQt5/#files" class="">https://pypi.org/project/PyQt5/#files</a> ) are uploaded with the<br class="">manylinux1 tag as well, so this is not a problem unique to my setup.<br class="">It looks like there might be two bugs:<br class="">1. PyQt5's minimum glibc version is not set correctly<br class="">2. For projects whose minimum glibc version is 2.5 or lower, which<br class="">PyQt5 currently is declared as, the wheel name is not generated<br class="">correctly on non-x86 platforms<br class=""></blockquote><br class="">Just 1. Hopefully fixed in the next snapshot.<br class=""><br class="">Phil<br class=""></div></div></blockquote></div><br class=""></div></div><div class="">Hi again,<div class=""><br class=""></div><div class="">It turns out there is a very similar issue for macOS AArch64 machines as well. PyQt-builder determines the minimum macOS SDK version to be 10.13 when building PyQt5.15. SIP then glues together the CPU architecture from the platform tag 'macosx-11.0-arm64' with the specified minimum macOS version to arrive at a wheel name of 'PyQt5-5.15.7-cp37-abi3-macosx_10_13_arm64.whl'. But pip rejects this; the Apple AArch64 CPUs are not supported before macOS 11 so the tag makes no sense. The only valid CPU architecture is 'universal2'. 'cp37-abi3-macosx_11_0_arm64' is the appropriate tag and once SIP is patched to generate that, everything builds and works fine.</div></div><div class=""><br class=""></div><div class="">It is possible to query pip for a list of tags a particular system is compatible with by running `pip debug --verbose`. On my macOS 12.5 system with the AArch64 processor and Python 3.10.5 and pip 22.1.2, this produces the following list: <a href="https://pastebin.com/AL5TxNJd" class="">https://pastebin.com/AL5TxNJd</a></div><div class=""><br class=""></div><div class="">Could SIP more intelligently determine the wheel name using this list? The ad-hoc logic currently present seems a bit brittle. I wonder if there is a third instance of this problem remaining with the Windows ARM machines too. I don't have access to one of those to check unfortunately.</div><div class=""><br class=""></div><div class="">Thanks for your time,</div><div class="">Thomas</div></body></html>