Build app for M1 / Apple Silicon

[dvcrn]

Since it's just python under the hood and python already compiles on M1, how difficult would it be to package an .app for M1/ARM macs?

Are there instructions available on how to build the .app from source? Would love to give it a go

[sanderjo]

To run from source, see https://sabnzbd.org/wiki/installation/install-macos

[dvcrn]

Ah yeah that I saw, but I meant more building an actual launchable app that could be distributed

[sanderjo]

I know. But you could start by running from source ... because I'm very curious if that gives better performance. Check via SABnzbd's upper right corner, click on the wrench symbol ("Status and interface options"), then click on first tab Status, and therev click on the Refresh Arrow.

[Cpuroast]

Maybe in time, a Universal 2 app can be made, but for now, you can run the Intel version via Rosetta 2 or try and run from sources via AS native code.

[dvcrn]

Okay, I'll run it from source for now and report back!

[Safihre]

https://www.python.org/downloads/release/python-391/

Seems like they released a version, so indeed we could build the app this way.
We have the build process actually now integrated in Github actions (see the open Pull request). So I think it should be possible to build it!
Let me try this week and report back.

[Safihre]

I tried, but so far it seems not everything is working yet. The compiled Python packages, for example sabyenc still compile for x64 on the build platforms.
I think we have to wait a bit more for the whole toolchains to be adapted to the new platform. Will keep this open as a reminder!

[dvcrn]

That's odd, I tried to run it from source and have no issues here at all. No error messages in the log either, it works as a direct 1:1 replacement for the Intel mac app. I installed python through brew though, but the formula is also just using a precompiled release.

Python

❯ brew info python
python@3.9: stable 3.9.1 (bottled)
Interpreted, interactive, object-oriented programming language
https://www.python.org/
/opt/homebrew/Cellar/python@3.9/3.9.1 (4,522 files, 72.7MB)
  Poured from bottle on 2020-12-18 at 13:08:06
/opt/homebrew/Cellar/python@3.9/3.9.1_1 (8,629 files, 129MB) *
  Built from source on 2020-12-19 at 19:07:08
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/python@3.9.rb

❯ python -VV
Python 3.9.1 (default, Dec 19 2020, 19:06:24)
[Clang 12.0.0 (clang-1200.0.32.28)]

Log:

2020-12-23 21:10:01,231::INFO::[SABnzbd:1142] --------------------------------
2020-12-23 21:10:01,232::INFO::[SABnzbd:1143] SABnzbd.py-3.2.0-develop
2020-12-23 21:10:01,232::INFO::[misc:983] [N/A] Running external command: ['git', 'rev-parse', '--short', 'HEAD']
2020-12-23 21:10:01,243::INFO::[SABnzbd:1153] Commit: 2d9dc480
2020-12-23 21:10:01,244::INFO::[SABnzbd:1154] Full executable path = /Users/david/src/sabnzbd/SABnzbd.py
2020-12-23 21:10:01,244::INFO::[SABnzbd:1164] Platform = posix
2020-12-23 21:10:01,244::INFO::[SABnzbd:1165] Python-version = 3.9.1 (default, Dec 19 2020, 19:06:24)
[Clang 12.0.0 (clang-1200.0.32.28)]
2020-12-23 21:10:01,244::INFO::[SABnzbd:1166] Arguments = "SABnzbd.py"
2020-12-23 21:10:01,244::INFO::[SABnzbd:1170] Not inside a docker container
2020-12-23 21:10:01,244::INFO::[SABnzbd:1173] Preferred encoding = UTF-8
2020-12-23 21:10:01,244::INFO::[SABnzbd:1185] SSL version = OpenSSL 1.1.1i  8 Dec 2020
2020-12-23 21:10:01,244::INFO::[SABnzbd:1237] Using INI file /Users/david/Library/Application Support/SABnzbd/sabnzbd.ini
2020-12-23 21:10:01,249::INFO::[postproc:139] Loading postproc queue
2020-12-23 21:10:01,249::INFO::[__init__:923] [N/A] /Users/david/Library/Application Support/SABnzbd/admin/Rating.sab missing
2020-12-23 21:10:01,250::INFO::[scheduler:177] Scheduling resume([]) on days [1, 2, 3, 4, 5, 6, 7] at 00:00
2020-12-23 21:10:01,250::INFO::[scheduler:186] Scheduling RSS interval task every 60 min (delay=54)
2020-12-23 21:10:01,250::INFO::[scheduler:197] Scheduling VersionCheck on day 6 at 9:47
2020-12-23 21:10:01,250::INFO::[scheduler:211] Setting schedule for midnight BPS reset
2020-12-23 21:10:01,250::INFO::[__init__:332] All processes started
2020-12-23 21:10:01,250::INFO::[SABnzbd:303] Template location for Glitter is /Users/david/src/sabnzbd/interfaces/Glitter
2020-12-23 21:10:01,250::INFO::[SABnzbd:303] Template location for Config is /Users/david/src/sabnzbd/interfaces/Config
2020-12-23 21:10:01,251::INFO::[SABnzbd:397] SABYenc module (v4.0.2)... found!
2020-12-23 21:10:01,251::INFO::[SABnzbd:416] Cryptography module (v3.3.1)... found!
2020-12-23 21:10:01,252::INFO::[SABnzbd:421] par2 binary... found (/Users/david/src/sabnzbd/osx/par2/par2-sl64)
2020-12-23 21:10:01,252::INFO::[SABnzbd:428] UNRAR binary... found (/Users/david/src/sabnzbd/osx/unrar/unrar)
2020-12-23 21:10:01,252::INFO::[SABnzbd:446] 7za binary... found (/Users/david/src/sabnzbd/osx/7zip/7za)
2020-12-23 21:10:01,252::INFO::[SABnzbd:457] nice binary... found (/usr/bin/nice)
2020-12-23 21:10:01,252::INFO::[SABnzbd:463] ionice binary... NOT found!
2020-12-23 21:10:01,254::INFO::[SABnzbd:1424] Starting web-interface on 0.0.0.0:8085
2020-12-23 21:10:01,254::INFO::[_cplogging:213] [23/Dec/2020:21:10:01] ENGINE Bus STARTING
2020-12-23 21:10:01,262::INFO::[notifier:122] Sending notification: SABnzbd - New release available : None (type=other, job_cat=None)
2020-12-23 21:10:02,367::INFO::[_cplogging:213] [23/Dec/2020:21:10:02] ENGINE Serving on http://0.0.0.0:8085
2020-12-23 21:10:02,367::INFO::[_cplogging:213] [23/Dec/2020:21:10:02] ENGINE Bus STARTED
2020-12-23 21:10:02,368::INFO::[SABnzbd:1461] Starting SABnzbd.py-3.2.0-develop
2020-12-23 21:10:02,376::INFO::[dirscanner:113] Dirscanner starting up

Running under Apple architecture

Steps:

$ virtualenv venv
$ source venv/bin/activate
$ pip install -r requirements.txt
$ python3 -OO SABnzbd.py

[sanderjo]

Nice.

Can you do something? In SABnzbd's upper right corner, click on the wrench symbol ("Status and interface options"), then click on first tab Status, and therev click on the Refresh Arrow ... what data do you get a CPU, pystones, etc?

[dvcrn]

Do you mean this screen?

[Safihre]

So yes it runs just fine from sources, but to build the App it's not just Python but also other compiled packages that need to be available for both architectures. That doesn't seem to work just yet.

[sanderjo]

Yes, that screen. Thanks.

So:

• CPU is "Apple processor" (without further specs ... might be a limitation of current Python 3.9.1), and Pystone is 326.000 ... which is extremely fast.
• Disks are fast, but not extremely fast
• Internet Bandwidth 0.1 MB/s ... what is going on there? Can you repeat the test to see if you get real speeds?

[dvcrn]

Internet Bandwidth 0.1 MB/s ... what is going on there? Can you repeat the test to see if you get real speeds?

I'm currently stuck on a slow shared LTE network connection for another week due to some provider problems, so the speed is sadly accurate. :) Repeating the test is giving me 0.2~0.3 MB/s.
For the disk, I was having sabnzbd on an external USB SSD which explains the low speed. I repeated the test with the internal disk and am getting 1069.6MB/s and 1177.9MB/s which sounds more right.

So yes it runs just fine from sources, but to build the App it's not just Python but also other compiled packages that need to be available for both architectures. That doesn't seem to work just yet.

If there is anything I can help with with this, happy to help!

[snipergotya]

I have setup this way after spending a few hours trying to get the app to work.

The app was painfully slow - took forever to check files and seemed to cap my download speed at 2-4MB/s.

following the source code option on the wiki I now get my full download speed.
Checking the file is pretty fast now. Thank god it is back to normal. It was driving me insane.

For more details of my process i have a post on reddit where i ran a few checks using the tool icon etc. All before I found this post talking about source setup.

https://www.reddit.com/r/SABnzbd/comments/krajqk/mac_mini_m1_issues/

[Safihre]

For now we are limited by PyInstaller, related issue: pyinstaller/pyinstaller/issues/5315

[sanderjo]

The app was painfully slow - took forever to check files and seemed to cap my download speed at 2-4MB/s.

Weird ... because @dvcrn reported great speeds with the x86-app (no: not source) above in this thread, see #1711 (comment)

[dvcrn]

Weird ... because @dvcrn reported great speeds with the x86-app (no: not source) above in this thread, see #1711 (comment)

Ah, I was running the speed tests with python compiled for M1 running sabnzbd, not the x86. Setup in #1711 (comment)

I didn't experience slow-ness like @snipergotya described. I'm back on the x86 version for the time being though because of the UI integrations that running from source doesn't have. No issues here either though. Just slightly slower than running natively

[snipergotya]

The app was painfully slow - took forever to check files and seemed to cap my download speed at 2-4MB/s.

Weird ... because @dvcrn reported great speeds above in this thread, see #1711 (comment)

The Sab test reported great speeds.
dvcrn never actually reported back with real world downloads.

As you can see in my reddit thread. my disk speed etc was super fast.
Download speed was shown as 18 MB/s according to the tool icon - but when it came down to actual downloading it struggled to go above 3-4mb/s and the file checking at the start, even for files under 1gb took minutes(i mean like 5mins+ ).

Using the source code option the thing is lightening quick, file checking is down in seconds and downloads are finished in seconds.
System Performance (Pystone)93339 Apple M1
Download folder speed14.7 MB/s (/Volumes/Media/Downloads…)
Complete folder speed13 MB/s (/Volumes/Media/Downloads)
Internet Bandwidth 25.3 MB/s (202.4 Mbps) in the source code install this isn't reflecting my speed, I actually get a faster speed.

File: xxxxx
Size813.3 MB
Download Downloaded in 19 seconds at an average of 42.0 MB/s

So the app when run on an M1 mac is unusable basically compare to the source code option.

[dvcrn]

So the app when run on an M1 mac is unusable basically compare to the source code option.

I have no issues with the x86 app running on my M1 Mac Mini through Rosetta2 here and speed-wise it's pretty much the same as when I had it hosted on my Intel Mac Mini. But I also don't have 25.3MB/s throughput here to test with... 😄

I tried grabbing a random release and get around 10 MB/s which is at the upper end of my connection

Download folder speed14.7 MB/s (/Volumes/Media/Downloads…)
Complete folder speed13 MB/s (/Volumes/Media/Downloads)

What kind of drive are you using for this? Seems a bit slow

[snipergotya]

Not sure what was wrong with my app then.

But mines completely struggled, seemed to freeze when it was unpacking files and halted the download until the unpacking was done etc.
Everything was super slow as if it struggled to get the resources it needed.

I'm just glad the source setup resolved my issues. My setup is back to normal and reliable again :)
Was almost considering going back to my windows pc.

[bryanhiestand]

For now we are limited by PyInstaller, related issue: pyinstaller/pyinstaller/issues/5315

It looks like they just updated PyInstaller when they merged pyinstaller/pyinstaller/pull/5883 and that issue was closed 13 days ago.

Thank you for all the legwork on this!

[Safihre]

This will still be a lot of work. Because all SABnzbd's dependencies also need to be compiled for M1.
Not sure how well that is going to work, because we have quite a few and specific ones like cryptography and pyobjc.

[thezoggy]

Just install and run from source and see what it says? The installer is one piece that you can skip by doing this.

[bryanhiestand]

This will still be a lot of work. Because all SABnzbd's dependencies also need to be compiled for M1.
Not sure how well that is going to work, because we have quite a few and specific ones like cryptography and pyobjc.

No worries, I'm not trying to push you on it, just wanted to update the thread about PyInstaller.

I haven't run into any issues yet. I'll compare running from source vs. just running the existing package under Rosetta. Everything seems to work fine so far.

[thezoggy]

If you try to run it natively can you report back what it errors on? (I have no clue at what libs or utilities we use even support m1 at this time)

[thezoggy]

right now our installer wont work for m1 because pyinstaller is set to 4.2:
https://github.com/sabnzbd/sabnzbd/blob/develop/builder/requirements.txt#L2

pyinstaller added M1 support in 4.4 (2021-07-13)
There was some bugs though which got fixed in version 4.5 (2021-08-01) - Fix architecture detection on Apple M1 (#6029)
latest is: 4.5.1 (2021-08-06)

[Safihre]

Will build a release with the new PyInstaller, it was fixed at 4.2 because 4.3 had a bug that broke all our releases.
But I doubt that it will create an M1 build, because not all our dependencies are universal2.

[Safihre]

Current status on 20-sep-2021:
To make a universal2 SABnzbd we need universal2 versions of all our dependencies.
pip only installs the current arch, so even if you are on an M1 it will only install arm64 and not x86_64.
In order to get universal2 we would need to re-compile every single dependency when building a release. This is possible of course.
However, we have some heavy dependencies: cryptography and pyobjc, which are a pain to compile.
I did a quick try, which failed due to missing OpenSSL-headers. Can be fixed of course, if someone wants to invest the time!
https://github.com/sabnzbd/sabnzbd/runs/3656092804?check_suite_focus=true

[thezoggy]

Wonder if we could use brew to have it install/compile during the build? What do other macros GitHub builder workflows do?

[Safihre]

@dvcrn could you check what's listed in Activity Monitor? https://www.google.com/amp/s/www.iphonetricks.org/how-to-check-if-app-is-optimized-for-m1-mac/amp/

It's not just SABnzbd itself that needs to be adjusted, the included tools (unrar, par2, 7zip) also need to be released with universal2 binaries. Right now they are all x86, so we would also have to recompile all those.

[dvcrn]

@dvcrn could you check what's listed in Activity Monitor? google.com/amp/s/www.iphonetricks.org/how-to-check-if-app-is-optimized-for-m1-mac/amp

Oh yeah sorry, it's all Apple, not Intel anymore 👍

[Safihre]

Great! So now I also wonder if it actually improves performance (faster speed, or lower cpu usage, lower battery usage), but that's quite hard to test..

[sanderjo]

@dvcrn What is "System performance (Pystone) " with the native M1 versus x86 ? It's under the Wrench symbol in the upper right corner of SABnzbd

[dvcrn]

Apple Silicon native:

x86:

Downloads folder is the internal SSD for this test. Both use identical configuration and I only swapped the .app out between the tests. This is on a M1 mac mini, no M1 Pro/Max.

[sanderjo]

Wow, impressive performance, and impressive performance leap!

[Safihre]

Closing this as resolved then!
@Cpuroast confirmed it also works on 10.9+, so that's actually really cool we can support all these platforms with 1 binary!
It got a bit fatter (21MB vs 15MB), but that seems a small price.

[puzzledsab]

On Windows 10/Intel I5 the Pystone fell from about 237k with 3.8 to about 195k with 3.10. The result seemed a lot more unstable as well, varying between 188k and 200k.

[Safihre]

@puzzledsab Not really the right issue for this, but yeah I can confirm on my Windows i7 I see the same thing.
The 3.5.0-develop release is 10-15% lower pystone compared to 3.4.2.
Wonder if users will start complaining of actual lower download speeds.. I will test on my slow Intel Celeron.
But now I'm getting really off-topic 😨

[thezoggy]

what if you use python 3.9 instead of 3.10 ?

[Cpuroast]

Weird, on macOS I saw a 20% increase in pystone with the latest build of 3.5.0 over 3.4.2.

But that uses python.org's python, so maybe they are doing something specific with the macOS binaries.

[Cpuroast]

Yeah, just ran it again and its consistent:
macOS 10.15.7(Catalina), 3rd gen quad-core mobile Core i7

3.4.2: ~100K
3.5.0-develop [cbeab4d]: ~120K

So it's definitely a win for macOS on both Intel and ARM.

[Safihre]

@dvcrn could you run this new M1 build from the command line (with the --console parameter) and then in Config General, enable Advanced Settings, and click the refresh icon next to the certificate paths? This will trigger a x86 part of the code. I wonder if it crashes.
If auccesfull it should print a INFO about auccesfull generated certificates.

[dvcrn]

Yes you're correct, it crashes because it can't find the arm64e files:

2021-11-19 11:43:50,184::INFO::[notifier:123] Sending notification: Error - Error creating SSL key and certificate (type=error, job_cat=None)
2021-11-19 11:43:50,184::ERROR::[misc:747] Error creating SSL key and certificate
2021-11-19 11:43:50,184::INFO::[misc:748] Traceback:
Traceback (most recent call last):
  File "sabnzbd/misc.py", line 741, in create_https_certificates
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "sabnzbd/utils/certgen.py", line 9, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/serialization/__init__.py", line 15, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/serialization/base.py", line 11, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/types.py", line 7, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/dsa.py", line 12, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/utils.py", line 6, in <module>
ImportError: dlopen(/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so, 0x0002): tried: '/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/_rust.abi3.so' (no such file)

/EDIT: Just to add, but calls to the x86 binaries like unrar work fine. It transparently executes them in rosetta2 if available. It's just unhappy when stuff like x86 and arm64 dls/parts get mixed

[Safihre]

@dvcrn Can you try this build?
Now all Python modules are compiled for universal2.
https://github.com/sabnzbd/sabnzbd/actions/runs/1481114919

[dvcrn]

Finally had some time to try this. I re-ran the same experiment as last time and hit the refresh button next to the certificate, but it's crashing with the same error as before

2021-11-22 15:45:30,272::INFO::[notifier:123] Sending notification: Error - Error creating SSL key and certificate (type=error, job_cat=None)
2021-11-22 15:45:30,272::ERROR::[misc:747] Error creating SSL key and certificate
2021-11-22 15:45:30,272::INFO::[misc:748] Traceback:

Traceback (most recent call last):
  File "sabnzbd/misc.py", line 741, in create_https_certificates
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "sabnzbd/utils/certgen.py", line 9, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/serialization/__init__.py", line 15, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/serialization/base.py", line 11, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/types.py", line 7, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/dsa.py", line 12, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/primitives/asymmetric/utils.py", line 6, in <module>
ImportError: dlopen(/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so, 0x0002): tried: '/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/_rust.abi3.so' (no such file)

_rust.abi3.so is still x86_64 only:

❯ file /Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so
/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_rust.abi3.so: Mach-O 64-bit dynamically linked shared library x86_64

Compared to _openssl.abi3.so which is universal:

❯ file /Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_openssl.abi3.so
/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_openssl.abi3.so: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64:Mach-O 64-bit bundle arm64]
/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_openssl.abi3.so (for architecture x86_64):       Mach-O 64-bit bundle x86_64
/Applications/SABnzbd.app/Contents/MacOS/cryptography/hazmat/bindings/_openssl.abi3.so (for architecture arm64):        Mach-O 64-bit bundle arm64

[dvcrn]

Actually that _rust.abi3.so looks to be the only non-universal library left:

❯ find /Applications/SABnzbd.app/Contents/MacOS/ -name "*so" -exec file {} \; | grep "Mach-O 64-bit dynamically linked"
/Applications/SABnzbd.app/Contents/MacOS//cryptography/hazmat/bindings/_rust.abi3.so: Mach-O 64-bit dynamically linked shared library x86_64

[Safihre]

@dvcrn Thanks for testing, I might just include that find command in the build pipeline so we never accidentially include something non-universal2!

Turns out cryptography is more difficult than expected, as explained here by the creators: pyca/cryptography#5918 (comment)
But, they also provide a universal2 build so will work now on pulling that in!

[Safihre]

@dvcrn Could you try again but with: https://github.com/sabnzbd/sabnzbd/actions/runs/1490977191 ?

[dvcrn]

Good news - everything is universal2 now! 🎉

When repeating the certificate task I'm now getting this now:

Traceback (most recent call last):
  File "sabnzbd/misc.py", line 743, in create_https_certificates
  File "sabnzbd/utils/certgen.py", line 24, in generate_key
  File "cryptography/hazmat/backends/__init__.py", line 9, in default_backend
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/backends/openssl/__init__.py", line 6, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/backends/openssl/backend.py", line 64, in <module>
  File "PyInstaller/loader/pyimod03_importers.py", line 476, in exec_module
  File "cryptography/hazmat/bindings/openssl/binding.py", line 14, in <module>
ImportError: dlopen(/Applications/SABnzbd.app/Contents/MacOS/_cffi_backend.cpython-310-darwin.so, 0x0002): symbol not found in flat namespace '_ffi_prep_closure'

Could be this? pyca/cryptography#5843

[Safihre]

Oke next try: https://github.com/sabnzbd/sabnzbd/actions/runs/1502929891
Maybe I'll get a cloud M1 for testing.

[dvcrn]

Sadly still the same error. I know how annoying this is to debug without access to a M1 machine so I appreciate the many attempts.

I want ahead and checked out the features/m1test branch and built from scratch with a virtualenv, then ran the binary and didn't get the error. Looking through the build script, it's linking with $(brew --prefix libffi) but it might be an older version with that issue mentioned in the thread above.

Can we add a brew info libffi into the build script? I'm not sure what the virtual environment on github allows but brew upgrade libffi might be needed (alternatively, install it manually - https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libffi.rb)

Local version I built with is 3.4.2

/EDIT: maybe I could fork and make a PR so I can dick around with the CI a bit

[Safihre]

It's also 3.4.2: https://github.com/sabnzbd/sabnzbd/runs/4321505528?check_suite_focus=true
Few lines above.

[Safihre]

Will rent a cloud M1 next week to fix this. For now I made one last attempt since I saw that PKG_CONFIG_PATH was not set. Maybe this worked?
https://github.com/sabnzbd/sabnzbd/actions/runs/1506749076

/EDIT: maybe I could fork and make a PR so I can dick around with the CI a bit

As you are not a contributor to sabnzbd yet, GitHub requires me to approve the CI every time when you make a PR. So you would have to create a fork and run the CI in your own fork.

[Safihre]

After almost a full day of debugging and not understanding anything about the strange world of configure and FLAGS I finally figured it out.
It turns out that the Homebrew version of libffi was only compiled for x86, so when cffi linked against it, it would produce an invalid cffi.universal2 binary. So forcefully uninstalling Homebrew libffi in GitHub Actions forces cffi to pick the libffi from Apple that is included with XCode. And that one is really universal2 🥳

I ended up renting an M1 instance from Scaleways to confirm. And it works now!

[dvcrn]

Great work @Safihre! So the suspicion that something is up with libffi was right

Very happy to see a full universal build 🔥