Apple Silicon: mach-o file, but is an incompatible architecture

[brucedjones]

Thanks for the swift response on updating the build to generate arm64 wheels. Unfortunately, after testing it seems something still isn't quite right.

Installing version 0.2.3 I see

Collecting robust_laplacian
  Downloading robust_laplacian-0.2.3-cp39-cp39-macosx_11_0_arm64.whl (367 kB)
     |████████████████████████████████| 367 kB 3.5 MB/s

Which appears to be the correct wheel. But when running import robust_laplacian I get:

ImportError: dlopen(/opt/homebrew/lib/python3.9/site-packages/robust_laplacian_bindings.cpython-39-darwin.so, 0x0002): tried: '/opt/homebrew/lib/python3.9/site-packages/robust_laplacian_bindings.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/robust_laplacian_bindings.cpython-39-darwin.so' (no such file), '/usr/lib/robust_laplacian_bindings.cpython-39-darwin.so' (no such file)

and the import ultimately fails. Somehow it seems that the arm64 wheel contains binaries compiled for x86_64

[nmwsharp]

Oh no! Thanks for spotting this. As you may have guessed I don't have an apple silicon / arm64 machine to test on.

Real quick, could you please check if the same problem exists with the polyscope package? I wonder if both of my build systems are broken, or I just messed up porting the changes here.

[brucedjones]

Yep same problem

Collecting polyscope
  Downloading polyscope-1.3.0-cp39-cp39-macosx_11_0_arm64.whl (2.6 MB)
     |████████████████████████████████| 2.6 MB 3.2 MB/s

ImportError: dlopen(/opt/homebrew/lib/python3.9/site-packages/polyscope_bindings.cpython-39-darwin.so, 0x0002): tried: '/opt/homebrew/lib/python3.9/site-packages/polyscope_bindings.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/polyscope_bindings.cpython-39-darwin.so' (no such file), '/usr/lib/polyscope_bindings.cpython-39-darwin.so' (no such file)

Happy to help out with debugging!

[brucedjones]

Just did a little digging, I manually downloaded robust_laplacian-0.2.3-cp39-cp39-macosx_11_0_arm64 and robust_laplacian-0.2.3-cp39-cp39-macosx_10_9_x86_64 from pypi and unpacked them. Both wheels contained an identically named file robust_laplacian_bindings.cpython-39-darwin.so which also happens to have the same checksum (74b6140ab5972357a995f51fb174c909 for reference).

So it would seem that either the same binary is being built for both architectures, or the wrong binary is being packaged

[nmwsharp]

oof, thanks for confirming that.

I just looked in to this a little, and I think I might know what the problem is. When cibuildwheel spins up containers to build the package, it's not actually running on an arm64 machine, it's running on an x86_64 machine but cross-compiling to arm64. This configuration should be okay, BUT my cmake script that compiles the underlying binary is unaware that it should be cross-compiling, and compiles the binary in x86_64 mode regardless. It seems that this gets detected by default based on the architecture of the cmake process, which is unsurprisingly x86_64.

So the fix should be to adjust this project's CMakeLists.txt to ensure that it respects the target architecture when cross-compiling, buuuuut I'm not quite sure how to do that yet.

Some interesting discussions:

• CMake, scikit-build, and Apple Silicon pypa/cibuildwheel#582
• https://stackoverflow.com/questions/64830635/why-does-my-native-application-compiled-on-apple-silicon-sometimes-build-as-arm6

[brucedjones]

ah makes sense. FWIW when i build robust-laplacian locally it does build with no problems and works fine, so there is hope!

[nmwsharp]

(leaving random thoughts here as I sort this out, I don't have a ton of time right now so it might take a little while)

It looks like the pybind folks have a new project specifically for the purpose of managing CMake builds for Python packages. https://scikit-build.readthedocs.io/en/latest/index.html. One of the main motivations listed is handling cross-compilation better. Perhaps rather than fixing this clumsily in CMake once, it would be better to port the build script to scikit-build.

[brucedjones]

Thanks for the breadcrumb! I did some digging and found the Parselmouth package had solved this problem. I made a PR with a proposed fix patterned off that package here: #8