Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universal wheel for macOS contains only x86_64 build #2154

Closed
Tracked by #2081
doronz88 opened this issue Sep 5, 2023 · 13 comments · Fixed by #2441
Closed
Tracked by #2081

Universal wheel for macOS contains only x86_64 build #2154

doronz88 opened this issue Sep 5, 2023 · 13 comments · Fixed by #2441
Labels
bug build & packaging Build system and packaging related python bindings
Milestone

Comments

@doronz88
Copy link

doronz88 commented Sep 5, 2023

When installing the package on an Apple Silicon, the universal wheel being installed is only for intel.

This can be examined:

file /opt/homebrew/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib
# outputs: /opt/homebrew/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib: Mach-O 64-bit dynamically linked shared library x86_64

As a result, capstone will fail to import on Apple Silicon.

@Rot127
Copy link
Collaborator

Rot127 commented Sep 5, 2023

Do you want to use Capstone for AArch64 binaries? If yes, I highly recommend to use the auto-sync branch and cherry-pick the commits from this PR to make it build on ARM Macs.
Regarding the wheel: cc @kabeor Any progress with this?

@doronz88
Copy link
Author

doronz88 commented Sep 5, 2023

I want it to not crash. Not even disassembling.

@XVilka XVilka mentioned this issue Sep 6, 2023
24 tasks
@XVilka
Copy link
Contributor

XVilka commented Sep 6, 2023

Added in #2081

@kabeor
Copy link
Member

kabeor commented Sep 6, 2023

Compile from Apple Silicon:

$ make -j8   
[  1%] Building C object CMakeFiles/capstone.dir/Mapping.c.o
[  1%] Building C object CMakeFiles/capstone.dir/MCInst.c.o
[  1%] Building C object CMakeFiles/capstone.dir/cs.c.o
[  3%] Building C object CMakeFiles/capstone.dir/MCInstPrinter.c.o
[  3%] Building C object CMakeFiles/capstone.dir/SStream.c.o
[  5%] Building C object CMakeFiles/capstone.dir/utils.c.o
[  5%] Building C object CMakeFiles/capstone.dir/MCInstrDesc.c.o
[  5%] Building C object CMakeFiles/capstone.dir/MCRegisterInfo.c.o
/Users/kabeor/capstone/MCInstPrinter.c:91:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
/Users/kabeor/capstone/MCInst.c:284:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.
1 error generated.
[  5%] Building C object CMakeFiles/capstone.dir/arch/ARM/ARMBaseInfo.c.o
make[2]: *** [CMakeFiles/capstone.dir/MCInst.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/capstone.dir/MCInstPrinter.c.o] Error 1
[  6%] Building C object CMakeFiles/capstone.dir/arch/ARM/ARMDisassembler.c.o
make[1]: *** [CMakeFiles/capstone.dir/all] Error 2
make: *** [all] Error 2

About MCInstPrinter.c, I guess default is missing from switch-case at line 88.

Since the code comes from #1949, Would you mind to have a look? @Rot127

@kabeor
Copy link
Member

kabeor commented Sep 11, 2023

Should be fixed in #2160.

However, the homebrew way is not maintaining by us, compiling source code is ok.

@doronz88
Copy link
Author

@kabeor I'll wait for the published .whl package to report when this issue is resolved

@orid95
Copy link

orid95 commented Oct 15, 2023

I'm also encountering the same problem. Is there a release schedule coming soon so I can install the package directly from pypi instead of building it myself?

@guyshe-jfrog
Copy link

A possible workaround could be to force it to build the x86_64 dylib, then link them together using lipo. But I can't seem to get the x86_64 dylib built. Even if I run

arch -x86_64 python setup.py bdist_wheel

The resulting dylib is arm64. Same result for the cython build.
This might also be a hint to what is going wrong, something is detecting the arch in a different way.

@XVilka
Copy link
Contributor

XVilka commented Jan 13, 2024

Should be fixed via a554a1d

@Rot127 Rot127 added this to the v5.0.2 milestone Mar 19, 2024
@Rot127 Rot127 added python bindings build & packaging Build system and packaging related bug labels Mar 20, 2024
@acama
Copy link

acama commented Aug 7, 2024

It seems like this is still not fixed

@XVilka
Copy link
Contributor

XVilka commented Aug 8, 2024

@acama it should be a part of the upcoming 5.0.2 release

@Rot127
Copy link
Collaborator

Rot127 commented Aug 8, 2024

@kabeor

@doronz88
Copy link
Author

The issue persists and should be reopened

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug build & packaging Build system and packaging related python bindings
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants