cp314t builds on armv7 images incorrectly produce aarch64 wheels

[ngoldbaum]

See PyO3/maturin#2701 and e.g. pyca/cryptography#12555 (comment). I have no idea if this is an issue in maturin or the manylinux images.

I can't reproduce the problem running the image locally on my ARM Mac but it happens reproducibly in the cryptography CI.

I'm reaching out in case you might have any ideas or suggestions to debug this.

[ngoldbaum]

I added debug output to the cryptography CI and it looks like the python executable is aarch64, for some reason:

https://github.com/pyca/cryptography/actions/runs/16656027857/job/47141128520?pr=12555#step:8:25

Linux-6.11.0-1015-azure-aarch64-with-glibc2.31

That's the output of this line: https://github.com/pyca/cryptography/actions/runs/16656027857/job/47141128520?pr=12555#step:8:10

/opt/python/cp314-cp314t/bin/python -c "import platform; print(platform.platform())"

So I think @alex's guess is correct and something is broken on the manylinux image.

What's odd is I don't see that on my Mac, using what I think is the same image:

goldbaum at Nathans-MBP in ~/Documents/cryptography on free-threaded-support
± docker run -it ghcr.io/pyca/cryptography-manylinux_2_31:armv7l
root@40e6c755c649:~# /opt/python/cp314-cp314t/bin/python -c "import platform; print(platform.platform())"
Linux-6.14.10-orbstack-00291-g1b252bd3edea-armv7l-with-glibc2.31

But I guess I'm also using orbstack?

[alex]

I'm not sure you want platform.platform() -- I think that's basically uname and will show you the kernel you're running on (you can run an armv7l binary on an arm64 kernel). I think you just want file on the binary to see what sort of elf it is.

[ngoldbaum]

Thanks for your patience, I've never tried to debug an issue like this.

Here's the output from file:

/opt/python/cp314-cp314t/bin/python: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=c4da7480a235c1b0695f51f5a8c036ab4b6f37a0, for GNU/Linux 3.2.0, stripped

It's identical on CI and locally on my Mac.

[alex]

Pretty sure that means the Python binary is correctly 32-bit ARM

…

On Thu, Jul 31, 2025 at 3:49 PM Nathan Goldbaum ***@***.***> wrote: *ngoldbaum* left a comment (pypa/manylinux#1825) <#1825 (comment)> Thanks for your patience, I've never tried to debug an issue like this. Here's the output from file: /opt/python/cp314-cp314t/bin/python: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=c4da7480a235c1b0695f51f5a8c036ab4b6f37a0, for GNU/Linux 3.2.0, stripped It's identical on CI and locally on my Mac. — Reply to this email directly, view it on GitHub <#1825 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBBN5BEEUQ27I23RLPT3LJXMVAVCNFSM6AAAAACC2SMRR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNBRGE2TSNBWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[mayeut]

The output of file shows that python is correctly built as armv7l.
The main difference between the build on macOS & the one on GHA is that macOS will use QEMU (even on Apple Silicon because those chips do not support running 32-bit code) whereas GHA arm runners will not use QEMU. This can be seen by running uname -m from within the container. You'll get armv7l on macOS and aarch64 on GHA (same difference mentioned by @alex for platform.platform()).
In order to try and reduce the differences, there's an entrypoint installed in all images but it's overridden/bypassed by the GHA cryptography workflow. You can try and see if doing the build using the entrypoint solves the issue (manylinux-entrypoint uv build ...).
That being said, I don't understand at first glance why there would be a difference between this python version and the other ones that are passing the build. The most likely answer is that it's somewhere in the build backend as it's the one that computes the output wheel name/platform.

[ngoldbaum]

The most likely answer is that it's somewhere in the build backend as it's the one that computes the output wheel name/platform.

The maturin maintainer agrees with you: PyO3/maturin#2701 (comment)

I guess this isn't a manylinux bug - I'll go ahead and close it in favor of the maturin issue.

[ngoldbaum]

It looks like using manylinux-entrypoint fixes it! cryptography's use of the images is pretty nonstandard. Not sure if you think the entry point is already sufficiently documented.