Problem with package: qiskit-terra

[JanLahmann]

Package name

qiskit-terra

Package version

0.25

PyPI URL

https://pypi.org/project/qiskit-terra/

piwheels URL

https://www.piwheels.org/project/qiskit-terra/

Python version

• Python 3.9
• Python 3.11

I am aware this is the issue tracker for a Python package index specifically for Raspberry Pi

• Yes

I have checked for duplicate issues

• Yes

I am the maintainer

• Yes

More information

Up to version 0.24.2, wheels with the standard naming/tags have been created, e.g. qiskit_terra-0.24.2-cp39-cp39-linux_armv7l.whl

Since Version 0.25.0, they have an unusual name/tag: qiskit_terra-0.25.0-cp38-abi3-linux_armv7l.whl.

A single wheel gets created for both OS versions (bullseye and bookworm).

However, the wheels contains a dependency on the OS (libc), it was created on.
When using this whl on 32-bit bullseye, the following error occurs:
File "/home/pi/qrasp/qrasp.py", line 48, in <module> from qiskit import IBMQ, execute, QuantumCircuit, ClassicalRegister, QuantumRegister File "/home/pi/.local/lib/python3.9/site-packages/qiskit/__init__.py", line 21, in <module> import qiskit._accelerate ImportError: /lib/arm-linux-gnueabihf/libm.so.6: version GLIBC_2.35' not found (required by /home/pi/.local/lib/python3.9/site-packages/qiskit/_accelerate.abi3.so)`

It seem like separate wheels need to be created for bullseye and bookworm.

Some additional background I learned from the Qiskit developer team:
"We build the packages using Python's limited C API that has a stable ABI (which is indicated by abi3). That lets us reduce the number of wheels we build because we target a minimum version of Python 3.8 (which is the py3.8) and the stability guarantees in Python's C API mean that one package file can be used with any Python version newer than Python 3.8"
However, there stills seems to be a dependency on the OS version, that needs different wheels to be built.

[JanLahmann]

This might also apply to rustworkx: https://www.piwheels.org/project/rustworkx/

[bennuttall]

Ugh, this is really annoying. We saw the same with cryptography in #464.

The abi3 tag says it's ABI-compatible with any Python 3. cp38 means it's compatible with Python 3.8 and above. But our builds are statically linked to libraries in a specific Debian version. Previously we could rely on the cp39/cp311 tag to keep them separate.

[JanLahmann]

I could imagine to "artificially" add a cp39/cp311 tag to these wheels when built on bullseye / bookworm.
That would make the wheels more restrictive (the tag would say it needs Python >= 3.9, while the code would also work with Python >=3.8), but then it would fit to the established tag scheme.
Not sure if that would lead to other issues, though.

[JanLahmann]

I think the tags cp39/cp311 are used in a dual meaning.
"cp39" is for "Python 3.9 AND built on bullseye"
"cp311" is for "Python 3.11 AND built on bookworm"

"cp38" is not well-defined, as it does not express what OS it is build on. (it's probably bookworm, but it does not exclude these wheels from being installed on bullseye)

[JanLahmann]

Might there be a similar issue with cmake (https://www.piwheels.org/project/cmake/) ?

One of my local wheel builds on 32-bit bullseye depends on cmake and fails with
/tmp/pip-build-env-50_no6rq/overlay/lib/python3.9/site-packages/cmake/data/bin/cmake: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

(a very similar error with cmake & libssl.so.3 causes this build to fail: https://www.piwheels.org/logs/0000/1232/1483.txt)

For cmake, also only a single wheel is provided (cmake-3.30.2-py3-none-linux_armv7l.whl) that is then being installed on both bullseye and bookworm.

[JanLahmann]

Is there an update on this issue?
As described int he comments, it might also affect several other packages.