Unable to install under M1 Macintosh mode (works in x86/rosetta 2 mode) #875
Replies: 34 comments 37 replies
-
|
It pip tries to install from sources like it does here, then the platform is not supported by any of the existing wheels. |
Beta Was this translation helpful? Give feedback.
-
|
If I am understanding what little documentation I have looked at regarding Travis CI. Xcode 12.0 is available by adding osx_image: xcode12u to your .travis.yml. And Xcode 12/12.2 support is what is needed for Universal support for M1 ARM... I believe. But I don't know if the travis.yml file is at Github's side, or a feature you directly control? Could you check and see if that's available, I would greatly appreciate it. |
Beta Was this translation helpful? Give feedback.
-
|
I can check what happens when I add that |
Beta Was this translation helpful? Give feedback.
-
|
Ok, made these changes to my ravis yml: They have the platform tag
|
Beta Was this translation helpful? Give feedback.
-
So just adding the compile tag for Travis CI obviously isn't the whole story... I did some more digging, and I wish to stress, this is the first time I've even looked at Travis, beyond seeing travis logs from builds in a few repositories... I know that it does work after being updated, because I was testing this for Pillow, and psycopg2. My understanding is that they updated their Travis CI builds to add ARM64 support. This is a travis ci build YAML from Microsoft (LWJGL/lwjgl3#601 (comment)), The major differences that I see are the cmake parameters (eg -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 vs -DCMAKE_OSX_DEPLOYMENT_TARGET=11.0) and the addition of the cmake architectures. I'm just surprised that I can't find any clear cut documentation on how to add this to Travis CI.... The appveyor.yml also was updated in that same commit to add "PLATFORM: ARM64", so maybe that also needs to be updated? https://github.com/LWJGL-CI/glfw/blob/c5ee7da34cad750429b1f2bea4c6ea7ed4e7de6f/appveyor.yml#L19 I just want to stress, I'll be happy to continue testing as needed. |
Beta Was this translation helpful? Give feedback.
-
|
I am a little lost at the moment. Reading some info about Rosetta2 I learned that this is some feature that supports x86 apps made for Intel processors to run on M1. It is an emulation. |
Beta Was this translation helpful? Give feedback.
-
|
It works fine under Rosetta 2, which I’d classify more of a translation than emulation.
But I’d be very surprised to see if it couldn’t be compiled under ARM, simply because a large amount of Android systems are ARM based…
Not that I can read it all, but this appears to be someone that says they’ve compiled it under arm.
https://www.cnblogs.com/pang1567/p/4083740.html <https://www.cnblogs.com/pang1567/p/4083740.html>
I’ll dig a bit, and maybe try to compile it myself….
- Benjamin
… On Jan 25, 2021, at 8:21 AM, Jorj X. McKie ***@***.***> wrote:
I am a little lost at the moment.
The examples you mentioned do not use cibuildwheel <https://github.com/joerick/cibuildwheel> like PyMuPDF. cibuildwheel has a set of supported target architectures platform tags - see here <https://cibuildwheel.readthedocs.io/en/stable/options/#build-skip>.
Reading some info about Rosetta2 I learned that this is some feature that supports x86 apps made for Intel processors to run on M1. It is an emulation.
I do not even know whether MuPDF can run / be generated on / for x64 M1 ...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#834 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZWK2FQX2XVMZZFZR6LS3VV5NANCNFSM4WERQXZA>.
|
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this helps, but from cibuildwheel:
1.8.0
22 January 2021
🌟 Added support for emulated builds! You can now build manylinux wheels on ARM64aarch64, as well as ppc64le and 's390x'. To build under emulation, register QEMU via binfmt_misc and set theCIBW_ARCHS_LINUX <https://cibuildwheel.readthedocs.io/en/latest/options/#archs> option to the architectures you want to run. See this <https://cibuildwheel.readthedocs.io/en/latest/faq/#emulation>FAQ entry <https://cibuildwheel.readthedocs.io/en/latest/faq/#emulation>FAQ entry <https://cibuildwheel.readthedocs.io/en/latest/faq/#emulation> for more information. (#482)
According to:
pypa/cibuildwheel#473 <pypa/cibuildwheel#473>
cibuildwheel gains an --arch option, which is set to native by default, building 32 & 64 bit where appropriate
If you include universal2 or arm64 in the arch list, then cibuildwheel downloads the new Python 3.9 (and 3.8 eventually, I think?) instead of the old one. Or this could toggle based on OS version or compiler version, but I think having it toggle based on command line options is better?
If the new Python is downloaded, then the trick linked previously is used to force x86_64 or arm64 as specified.
The main issue I see, which echo’s my issues earlier, is to insure you have the latest PIP, packaging, wheel modules. They all have upgrades need to support the M1.
But it appears that cibuildwheel may still be working on ARM M1 support?
- Benjamin
… On Jan 25, 2021, at 8:21 AM, Jorj X. McKie ***@***.***> wrote:
I am a little lost at the moment.
The examples you mentioned do not use cibuildwheel <https://github.com/joerick/cibuildwheel> like PyMuPDF. cibuildwheel has a set of supported target architectures platform tags - see here <https://cibuildwheel.readthedocs.io/en/stable/options/#build-skip>.
Reading some info about Rosetta2 I learned that this is some feature that supports x86 apps made for Intel processors to run on M1. It is an emulation.
I do not even know whether MuPDF can run / be generated on / for x64 M1 ...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#834 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZWK2FQX2XVMZZFZR6LS3VV5NANCNFSM4WERQXZA>.
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I have read this: |
Beta Was this translation helpful? Give feedback.
-
All this is covered in one go, when the wheel generation requets is sent to Travic CI. The numerous options and "export" variables, like the one mentioned above, just control the amount of different wheels generated. |
Beta Was this translation helpful? Give feedback.
-
On Linux with docker installed, registering qemu via binfmt_misc can be as easy as: docker run --rm --privileged multiarch/qemu-user-static --reset -p yesno idea if that works on OS X though. Might still be helpful to have arm wheels for linux though. |
Beta Was this translation helpful? Give feedback.
-
|
Cibuildwheel's master branch supports Universal2 and ARM64, if you,d like to try it out. You have to use pip 21.0.1 to install the universal2 wheels. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent step forward... But pip keeps trying to build the wheel? Do I need to manually download the wheels? (Are they not posted yet?) Never mind, the brain just caught up, I went to the (formerly) mentioned page where we had the wheels before and downloaded it. So it appears that the name of the file isn't correct? Working on that assumption, I renamed the wheel. The Mach-o reference, I believe is a reference to Power-PC / Rosetta, which is the original "Universal"? Silly question, maybe? Assuming they just added a "2" to the end of the Universal tag, could a 2 have been accidentally forgotten in the configuration file or something? |
Beta Was this translation helpful? Give feedback.
-
|
You have to build the module with Universal2 support (Clang compiles both arch's). In the latest master of cibuildwheel, you have to explicitly ask for universal2 or arm (or both), then it produces extra wheels, setting various things to make that happen during the compile. You have to have the latest AppleClang, which is true on the 10.15 macOS image on GitHub Actions / Azure. If you want to do it without cibuildwheel, you have to use macOS 11 and download the Universal2 version of Python from python.org. |
Beta Was this translation helpful? Give feedback.
-
|
I am currently trying this to generate a Linux ARM64 wheel. <...>
jobs:
include:
- os: linux
python: '3.7'
services:
- docker
env: PIP=pip
before_script:
- docker pull tonistiigi/binfmt
- docker run --privileged --rm tonistiigi/binfmt --install arm64
<...>
script:
- export CIBW_ARCHS_LINUX="aarch64"
<...>I hope one of these fiddlings lead to results some time ... |
Beta Was this translation helpful? Give feedback.
-
|
And also use the latest commit or two from cibuildwheel. |
Beta Was this translation helpful? Give feedback.
-
|
I'd make a PR if I knew where. :) |
Beta Was this translation helpful? Give feedback.
-
|
Ahh, that at least worked! Hope they are a help... |
Beta Was this translation helpful? Give feedback.
-
|
Well. After a few renames, it does load, but I get a circular import issue? |
Beta Was this translation helpful? Give feedback.
-
|
You can't load a Linux wheel on macOS... |
Beta Was this translation helpful? Give feedback.
-
|
I didn't expect it to work, but I was asked to try. Or at least that's the way that I read the implication (please find the following wheels in https://github.com/pymupdf/PyMuPDF-wheels/tree/linux) |
Beta Was this translation helpful? Give feedback.
-
|
These above wheels are one of the alternative architectures offered by cibuildwheel, a complete list seems to be this: |
Beta Was this translation helpful? Give feedback.
-
|
If you use current master (ideally, select the most recent commit so things don't randomly change), then it should work like this: - uses: joerick/cibuildwheel@08401d6608af90229133374071bcd056e84070c8
env:
CIBW_ARCHS_MACOS: "x86_64 universal2 arm64"Now it will try to build universal and arm64 wheels (might not want both; the universal2 + x86_64 should be fine unless the package is large, since universal2 will be potentially up to twice the size) |
Beta Was this translation helpful? Give feedback.
-
|
Have we gotten anywhere here? I believe some other cibuild workflow based repositories are now working under m1 mode? Is there something I can assist with or test? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, quite a few projects have successfully produced Universal2 wheels or Arm64 wheels using cibuildwheel 1.9.0+. |
Beta Was this translation helpful? Give feedback.
-
|
Well, Universal2 is a bit of a misleading name, as I understand it. It's Python's labeling for Rosetta2, which is the Intel translation for the M1. Which I already have working... But I installed it, and it resulted in the same error. |
Beta Was this translation helpful? Give feedback.
-
|
Hm - don't know what to try next. |
Beta Was this translation helpful? Give feedback.
-
|
Latest Pip is indeed installed, but setup tools was out of date.
Upgraded setup tools, and there was no change.
I’m just guessing here, but from what I think I see in the YAML is that you are building your own version of mupdf and putting that into the wheel?
What I realized from debugging with pyscopg2’s author, is that everything has to be compiled identically.
For example, when I was setting up postgres as M1 native, I also had to ensure that the DLL that the psycopg2 client was using was M1 native (even though it’s not bundled with psycopg2).
So could you be building an non-m1 native version of mupdf? And bundling that with the amd64 version of pymupdf?
Now that’s a bit strange, the universal2 wheel does not install under Rosetta2…
So I do suspect there’s something going on…
(This is in an rosetta 2 terminal session, so under Intel translation)
```
(downloader) benjamin@Nerv python % pip install /Volumes/4TB_Drive/sorted_downloads/2021-03-11/PyMuPDF-1.18.10-cp39-cp39-macosx_10_9_universal2.whl
ERROR: PyMuPDF-1.18.10-cp39-cp39-macosx_10_9_universal2.whl is not a supported wheel on this platform.
(downloader) benjamin@Nerv python % pip install pymupdf
Collecting pymupdf
Using cached PyMuPDF-1.18.9-cp38-cp38-macosx_10_9_x86_64.whl (5.6 MB)
```
- Benjamin
… On Mar 11, 2021, at 3:00 AM, Jorj X. McKie ***@***.***> wrote:
Hm - don't know what to try next.
You do have the most current pip installed, haven't you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#875 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZUNKUYTQN6N2DLKJW3TDB2BVANCNFSM4XABEVNA>.
|
Beta Was this translation helpful? Give feedback.
-
Definitely yes! The YAML script starts its run in a freshly created virtual machine and does what I describe in the installation docu for installing from sources:
Of course! That's why we have that option So if the |
Beta Was this translation helpful? Give feedback.
-
|
If there are shared libraries created using BEFORE_BUILD, they will be x86 only, meaning that the Universal2 wheel will only have the x86 half, and the Arm64 wheel will have the x86 parts stripped out, leving nothing at all. Universal2 is the macOS name for something that has both x84 and arm64 binaries present. It runs (without emulation) on both AS and Intel. It's generally 2x bigger, so whatever the x86 wheel size is, the Universal2 wheel should be roughly twice that size. Universal2 is a macOS thing, though support for a wheel with a universal2 name was added (mostly) in pip 21.0.1. |
Beta Was this translation helpful? Give feedback.
-
This YAML successfully creates 64bit Python shared library binaries since several years now (Linux and Max OSX - for 64bit Python desktop versions). At the "before build" stage only |
Beta Was this translation helpful? Give feedback.
-
|
Well, if you are linking to a static library, and the static library only contains x86 code, the same thing will happen, just in the linking stage instead of in |
Beta Was this translation helpful? Give feedback.
-
|
I am sorry I've following this document but I can't figure out how to solve this error. I've installed PyMuPDF using arm64 wheel and can you guys explain how to solve this error? |
Beta Was this translation helpful? Give feedback.
-
No - at least I cannot. This is still under investigation by @henryiii and other experts in the That the generated wheels in the |
Beta Was this translation helpful? Give feedback.
-
|
The problem is that the initial step is building or downloading libraries that are not universal2, so the universal2 wheel is really just x86 + nothing, and the Arm wheel is just nothing (for the libraries). Maybe the CMake variables for building Universal need to be set? pypa/cibuildwheel#582 Haven't had a chance to look into it in detail, except to find that the regular variables are being set in the BEFORE_BUILD environment. pypa/cibuildwheel#618 |
Beta Was this translation helpful? Give feedback.
-
|
Following the merge of #988 you should be able to build/install PyMuPDF with your local toolchain. On an ARM M1 Mac, with native homebrew & pip in place, these steps should work (the second step being replaced by |
Beta Was this translation helpful? Give feedback.
-
|
Ship it! It works! <grin>
I now have my gallery app working in M1 Native!
I can’t prove this yet, but memory usage appears to be quite a bit less, in M1 native, but that could simply be due to not having been running for long enough at this point.
- Benjamin
… On Mar 31, 2021, at 5:58 PM, Bastien Gandouet ***@***.***> wrote:
Following the merge of #988 <#988> you should be able to build/install PyMuPDF with your local toolchain. On an ARM M1 Mac, with native homebrew & pip in place, these steps should work (the second step being replaced by pip install pymupdf as soon as the referenced PR reach PyPI):
brew install mupdf swig
pip install https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#875 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZVOUCC2YLPZBD5LSY3TGOLI5ANCNFSM4XABEVNA>.
|
Beta Was this translation helpful? Give feedback.
-
|
I ran into an error: Was able to fix it with |
Beta Was this translation helpful? Give feedback.
-
|
This worked for me, and without installing freetype it did not work. I think the installation docs for pymupdf should be updated because these three lines seem to be the only way to get pymupdf working on an apple mac with the m1 chip. Seeing the hardships in building pymupdf for apple m1, the experience of the builders of opencv might help: https://opencv.org/opencv-python-for-apples-m1-chip-a-detective-story-with-a-happy-ending/ |
Beta Was this translation helpful? Give feedback.
-
|
The three lines are brew install mupdf swig |
Beta Was this translation helpful? Give feedback.
-
|
Is there some reason that I still have to uninstall and re-install using: pip install https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz instead of being able to upgrade via the standard pip install --upgrade pymupdf? Have the changes in master not yet been released into a general release? |
Beta Was this translation helpful? Give feedback.
-
|
@bschollnick - as I wrote in a post yesterday, I have to migrate away from Travis CI. I decided to use Github actions for creating pymupdf wheels instead. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I am getting an error indicating that the WHL is not a zip file?
```
(downloader) benjamin@Nerv python % pip install https://github.com/pymupdf/PyMuPDF-wheels/blob/osx/PyMuPDF-1.18.15-cp38-cp38-macosx_10_9_universal2.whl
Collecting PyMuPDF==1.18.15
Downloading https://github.com/pymupdf/PyMuPDF-wheels/blob/osx/PyMuPDF-1.18.15-cp38-cp38-macosx_10_9_universal2.whl
\ 109 kB 1.4 MB/s
ERROR: Exception:
Traceback (most recent call last):
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/cli/base_command.py", line 180, in _main
status = self.run(options, args)
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/cli/req_command.py", line 204, in wrapper
return func(self, options, args)
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/commands/install.py", line 318, in run
requirement_set = resolver.resolve(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 103, in resolve
r = self.factory.make_requirement_from_install_req(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 429, in make_requirement_from_install_req
cand = self._make_candidate_from_link(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 200, in _make_candidate_from_link
self._link_candidate_cache[link] = LinkCandidate(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 306, in __init__
super().__init__(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 151, in __init__
self.dist = self._prepare()
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 234, in _prepare
dist = self._prepare_distribution()
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 317, in _prepare_distribution
return self._factory.preparer.prepare_linked_requirement(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/operations/prepare.py", line 508, in prepare_linked_requirement
return self._prepare_linked_requirement(req, parallel_builds)
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/operations/prepare.py", line 570, in _prepare_linked_requirement
dist = _get_prepared_distribution(
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/operations/prepare.py", line 61, in _get_prepared_distribution
return abstract_dist.get_pkg_resources_distribution()
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/pip/_internal/distributions/wheel.py", line 27, in get_pkg_resources_distribution
with ZipFile(self.req.local_file_path, allowZip64=True) as z:
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/zipfile.py", line 1269, in __init__
self._RealGetContents()
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/zipfile.py", line 1336, in _RealGetContents
raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
```
If I download it locally, and then install from the WHL, it installs.
But fails if I go to import it.
```
(downloader) benjamin@Nerv python % python
Python 3.8.2 (default, Apr 8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>> import fitz
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/fitz/__init__.py", line 2, in <module>
from fitz.fitz import *
File "/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/fitz/fitz.py", line 15, in <module>
from . import _fitz
ImportError: dlopen(/Users/benjamin/venvs/downloader/lib/python3.8/site-packages/fitz/_fitz.cpython-38-darwin.so, 2): Symbol not found: _fz_default_color_params
Referenced from: /Users/benjamin/venvs/downloader/lib/python3.8/site-packages/fitz/_fitz.cpython-38-darwin.so
Expected in: flat namespace
in /Users/benjamin/venvs/downloader/lib/python3.8/site-packages/fitz/_fitz.cpython-38-darwin.so
>> ^D
```
Now after removing the bad install, if I do:
pip install https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz <https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz>
```
(downloader) benjamin@Nerv python % pip install https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz
Collecting https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz
Downloading https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz
- 6.0 MB 997 kB/s
Building wheels for collected packages: PyMuPDF
Building wheel for PyMuPDF (setup.py) ... done
Created wheel for PyMuPDF: filename=PyMuPDF-1.18.14-cp38-cp38-macosx_10_14_arm64.whl size=28323617 sha256=95751e98aca54d4abfeb68913e8160ac7096059c65ef3bcc495ddd715f10078d
Stored in directory: /private/var/folders/6g/0vldjqgd5d55rdv163phqh6r0000gn/T/pip-ephem-wheel-cache-e1fgpgng/wheels/56/32/26/4c5ffd496ee65098d82b5cb3bb2a95bab38ad861dd3ff423a9
Successfully built PyMuPDF
Installing collected packages: PyMuPDF
Successfully installed PyMuPDF-1.18.14
(downloader) benjamin@Nerv python % python
Python 3.8.2 (default, Apr 8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>> import fitz
```
Everything works fine. So, what is the difference between installing from the master directly, and the wheel?
- Benjamin
… On Jun 21, 2021, at 7:45 AM, Jorj X. McKie ***@***.***> wrote:
@bschollnick <https://github.com/bschollnick> - as I wrote in a post yesterday, I have to migrate away from Travis CI. I decided to use Github actions for creating pymupdf wheels instead.
While I am of course still new to github actions, I think I am having success creating OSX wheels.
Can you please have a look at this <https://github.com/pymupdf/PyMuPDF-wheels/tree/osx> repo branch and try out the wheel(s) relevant for you?
If you confirm it works for you, I will include those wheels on PyPI with the next version of pymupdf.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#875 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZRTD5KXVAFJYHTBRF3TT4Q4VANCNFSM4XABEVNA>.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for testing this! Let's forget the faulty error "no zip" file at the moment. Obviously a wrong message, because your alternative approach proved it is a ZIP file. Why my universal2 wheel does not run is serious in contrast. I will give it another try with a slightly different approach in the respective Github Action. Why your wheel 1.18.14 generation is working is puzzling to me! |
Beta Was this translation helpful? Give feedback.
-
|
You know what really confuses me, and maybe @henryiii can give us a hand here: The situation is different in your case if you do the MuPDF build on your M1 - like you obviously did sometime. |
Beta Was this translation helpful? Give feedback.
-
|
If the assessment in my previous post is correct, then as a consequence, PyMuPDF will be available on M1 machine only by generating it from sources - forever! |
Beta Was this translation helpful? Give feedback.
-
|
Well, with Apple killing off Intel Macs, pretty sure this won't be "forever"! Currently, you have to cross compile on public CI, yes. The CMake variables for cross-compile are discussed in pypa/cibuildwheel#582. |
Beta Was this translation helpful? Give feedback.
-
|
From My notes:
Following the merge of #988 you should be able to build/install PyMuPDF with your local toolchain. On an ARM M1 Mac, with native homebrew & pip in place, these steps should work (the second step being replaced by pip install pymupdf as soon as the referenced PR reach PyPI):
brew install mupdf swig
pip install https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz <https://github.com/pymupdf/PyMuPDF/archive/master.tar.gz>
So yes, I do have mupdf and swig installed via homebrew.
- Benjamin
… On Jun 21, 2021, at 6:12 PM, Jorj X. McKie ***@***.***> wrote:
Thanks for testing this!
Let's forget the faulty error "no zip" file at the moment. Obviously a wrong message, because your alternative approach proved it is a ZIP file.
Why my universal2 wheel does not run is serious in contrast. I will give it another try with a slightly different approach in the respective Github Action.
Why your wheel 1.18.14 generation is working is puzzling to me!
It is a generation from sources, so you are doing it on a M1 machine, right? And you must have previously installed MuPDF on that machine, too ... as well as SWIG, because PyMuPDF's C-source fitz_wrap.c and the Python interface fitz.py files are missing in that download.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#875 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHPEZQGS74OH2BSSPJUMIDTT62OPANCNFSM4XABEVNA>.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok then. The PR #988 did find its way into the Anyway, the bottom line remains, that I cannot provide wheels for the M1 version of OSX. For these machines a source generation must happen - at least until someone sponsors me an M1 mac 😉. |
Beta Was this translation helpful? Give feedback.
-
|
didn't Work for me, sadly :( |
Beta Was this translation helpful? Give feedback.
-
|
PyMuPDF breaks on macOS/ARM at version |
Beta Was this translation helpful? Give feedback.
-
|
Just to make sure this is not missed, repeating my request on #1563, could you post how you attempted to install pymupdf-1.20.0 on macOS/ARM? |
Beta Was this translation helpful? Give feedback.
-
|
Just to be clear, the workaround in #1563 is to do |
Beta Was this translation helpful? Give feedback.
-
|
If you have |
Beta Was this translation helpful? Give feedback.
-
|
We currently do not have a I wasn't aware that requiring (The interaction of |
Beta Was this translation helpful? Give feedback.
-
|
PEP 517 allows the build hook to specify if it has any dependencies for building SDists and any dependencies for building wheels. From day 1 the setuptools PEP 517 build hook has specified that it needs |
Beta Was this translation helpful? Give feedback.
-
|
Ah, interesting and good to know, thanks. This whole area seems a bit of a mess to me. For example no similar dependency exists when doing And this might be related to the workaround discussed on this page - installing |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm it works on my M1 in poetry too (no need to use that specific pip archive): brew install mupdf swig freetype
poetry add pymupdf |
Beta Was this translation helpful? Give feedback.
-
|
I had to install |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for mentioning this here. I've updated the installation documentation in my tree accordingly, so this information will be in the next release. |
Beta Was this translation helpful? Give feedback.
-
I am unable to install pymupdf under Mac OS X Big Sur Native M1 (eg pip install PyMuPDF), whereas in Intel mode (Rosetta 2/aka Intel translation mode) it works without any issue.
It appears that it is being built and the wheel is being ignored.
Your configuration (mandatory)
MAc OS X Big Sur, M1 Mac Mini w/16 Gb Ram
Python 3.9.1 (default, Jan 8 2021, 12:11:08)
[Clang 12.0.0 (clang-1200.0.32.28)] on darwin
PyMuPDF Using cached PyMuPDF-1.18.6.tar.gz (258 kB)
Additional context (optional)
I suspect that the Universal 2 wheel just needs to be created. Cryptography, and Pillow within the last day, just started to work in M1 Native mode, due to Wheel support being added to the build systems...
If there is anything that I can assist with or help, please feel free to let me know. I'd be happy to assist.
Beta Was this translation helpful? Give feedback.
All reactions