osx-arm64 seem to be broken

[mariusvniekerk]

Kills the python process at import time

import 'cryptography.hazmat' # <_frozen_importlib_external.SourceFileLoader object at 0x102ae2d60>
# /Users/marius/mambaforge/envs/flight/lib/python3.9/site-packages/cryptography/hazmat/bindings/__pycache__/__init__.cpython-39.pyc matches /Users/marius/mambaforge/envs/flight/lib/python3.9/site-packages/cryptography/hazmat/bindings/__init__.py
# code object from '/Users/marius/mambaforge/envs/flight/lib/python3.9/site-packages/cryptography/hazmat/bindings/__pycache__/__init__.cpython-39.pyc'
import 'cryptography.hazmat.bindings' # <_frozen_importlib_external.SourceFileLoader object at 0x102ae2d00>
# trying /Users/marius/mambaforge/envs/flight/lib/python3.9/site-packages/cryptography/hazmat/bindings/_rust.cpython-39-darwin.so
# trying /Users/marius/mambaforge/envs/flight/lib/python3.9/site-packages/cryptography/hazmat/bindings/_rust.abi3.so

KILLED 137

[h-vetinari]

I don't have an M1 to test this, unfortunately. Is that with 35.0? The only relevant change in the build instructions was this one but the build failed to compile without that (see #70). It's possible that that was not a full fix.

[anjos]

I wonder if cryptography/hazmat/bindings/_rust.abi3.so is compiled correctly. Loading cryptography/hazmat/bindings/_openssl.abi3.so which is just by its side works well. The command file reveals the following for both:

(test) $ file /Users/admin/mamba/envs/test/lib/python3.9/site-packages/cryptography/hazmat/bindings/*.so
/Users/admin/mamba/envs/test/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: Mach-O 64-bit bundle arm64
/Users/admin/mamba/envs/test/lib/python3.9/site-packages/cryptography/hazmat/bindings/_rust.abi3.so:    Mach-O 64-bit dynamically linked shared library arm64

I wonder if _rust.abi3.so should not also be a bundle.

[anjos]

I confirm this problem is reproducible with version 3.4.8 and 35.0.0, but not with 3.4.7.

[anjos]

Seems like an upstream problem in pyca/cryptography#6466

[anjos]

This problem seems to be related to the fact we are cross-compiling here. From what I gather from PyO3/setuptools-rust#10 (PyO3/setuptools-rust#134), that package does not support cross-compilation yet. The version of setuptools-rust at conda-forge is also unpatched, stock 0.12.1. Therefore, we may be just using the wrong binary?

[h-vetinari]

This problem seems to be related to the fact we are cross-compiling here.

Hm yes, the recent addition of a rust dependency, coupled with the necessary cross-compilation for osx-arm (since we don't have native CI) and lack of PyO3 support for cross-compilation sounds like this could be the cause.

Pinging @conda-forge/help-osx-arm64 how to best tackle this. As it is, we probably have to mark the osx-arm builds for 3.4.8 & 35.0.0 broken.

[isuruf]

A rebuild should fix this. Issue was clang-12 was used, but it was a bad build. To avoid these sort of issues in the future, add compiler('c') to build.

[h-vetinari]

Thanks for the tip @isuruf! Done in #79.

[h-vetinari]

@mariusvniekerk @anjos @TV4Fun

New osx-arm builds have been uploaded - could you please try again if the problem has been solved?

[anjos]

Thanks, I confirm it is now working well in our use-case (through python-gitlab -> requests).

[h-vetinari]

OK, thanks for testing, that's great to hear.

Will give it a bit more time for others to respond, but it sounds like this issue can be closed. 🙃

[h-vetinari]

OK, closing this now. Let us know if there are any more issues.