Hi Bill, Currently I’m building native arm64. Using Qt5. Haven’t tried to build universal binaries.
best, alex > On Aug 27, 2021, at 1:40 AM, Bill Somerville via wsjt-devel > <wsjt-devel@lists.sourceforge.net> wrote: > > > Hi Alex, > > I am a little confused. Is this post about building WSJT-X on an M1 silicon > macOS system, but producing x86_64 binaries, or are you really documenting > how to build native arm64 binaries (or better still universal binaries that > support both native x86_64 and arm64). If you are describing building for an > x86_64 target intended to run on M1 silicon using the Rosetta 2 emulator, > then you should state that. > > Anyway, for those that want to run WSJT-X on Apple M1 silicon, the current > solution (available at least until Qt has builds for arm64 on macOS, and > WSJT-X supports that Qt version - currently Qt 6.2), the existing macOS we > publish works just fine on M1 silicon by using the Rosetta 2 emulator. > Despite the emulation layer, the performance seems more than adequate. > > 73 > Bill > G4WJS. > > On 27/08/2021 03:33, Alex Lelievre via wsjt-devel wrote: >> Of course, the minute I sent that email- I figured it out. When I >> re-signed the app I didn’t pass the ‘—deep' option which was the key. >> >> Passing —deep to 'codesign -vvvv --deep wsjtx.app’ resulted in: >> wsjtx.app: invalid signature (code or signature have been modified) >> In subcomponent: >> /Users/alex/wsjtx-2.5.0-rc3/wsjtx.app/Contents/PlugIns/imageformats/libqwebp.dylib >> >> So signing it with with —deep fixed the problem! Yay!! >> >> >> >> Guess what? The app comes up and is running smoothly decoding FT8 (that’s >> all I’ve tested so far). Anyway, Apple M1 is now sorta supported- I guess >> I didn’t have a long way to go- :) >> >> WSJT-X uses 3.5% CPU on my MacBook Air M1. jt9 uses 2.2 % on average. >> jt9 on my fancy MacBook Pro Intel 2.4 GHz 8-Core Intel Core i9 with 32 GB of >> RAM uses 26%. >> Mind you- that comparison isn’t apples to apples as the Intel Mac is hooked >> to a radio and the M1 is listening to the microphone with me playing music. >> >> alex K6LOT >> >>> Begin forwarded message: >>> >>> From: Alex Lelievre <a...@foinc.com> >>> Subject: WSJT-X for Apple M1? >>> Date: August 26, 2021 at 7:06:00 PM PDT >>> To: WSJT software development <wsjt-devel@lists.sourceforge.net> >>> >>> My guess here is that not many folks use WSJT-X on Macs. :) >>> >>> I wanted to see if anyone else has attempted to build WSJT-X for M1 Macs? >>> >>> I’ve managed to build the entire source using the latest compilers and even >>> got it to link with a bit of hacking on the M1 (mostly around bogus -Xclang >>> arg being sent to gfortran and missing __chkstk_darwin() symbol in wsprd.c >>> only on M1). >>> >>> I’m working on some issues getting the app to launch. With the more modern >>> OS (MacOS X 12), signing is required and I’m running into some issues >>> there. It seems that there might be some signing going on by default >>> that’s causing the app to get killed on launch with a EXC_BAD_ACCESS >>> (SIGKILL (Code Signature Invalid)). As a result I tried signing the app >>> manually by replacing any signature that was there using a provision I >>> created. ‘codesign -vvvv wsjt.app’ reports wsjtx.app: is valid on disk — >>> wsjtx.app: satisfies its Designated Requirement, but the OS doesn’t agree. >>> It might need to be notarized as well. spctl reports './wsjtx.app: invalid >>> signature (code or signature have been modified)’ which is kinda true. >>> >>> I wanted to reach out and see if anyone else has tried to build for M1 and >>> possibly ran into this. I realize I still have a long way to go >>> considering I’m using the latest gfortran which is known to be >>> incompatible. But I figured I’d deal with that once I got the app to >>> launch! Baby steps... ;-) >>> >>> The M1 Mac is ridiculously fast at compiling this source so I can imagine >>> it will decode FT8, etc. with ease. Plus at some point we should make this >>> work. heh… >>> >>> Anyway thanks for everyone’s help so far with building WSJT-X for Big Sur >>> (I finally have that working). >>> best, >>> alex K6LOT >>> >>> >>> >>> p.s. I’ve been keeping notes and will publish the steps necessary to build >>> WSJT-X from the tarball on M1 or any Mac (including all the packages to >>> install via Brew) if anyone is interested. >>> >>> p.p.s. I also wanted to follow up and say that the issue with App Napping >>> was resolved, John (G4KLA) and I verified that disabling the local app >>> napping setting gets rid of the problem with failed decodes when in the >>> background and the system is under load… I understand our workaround has >>> been added to the Mac Readme but I have not verified that yet or tested the >>> steps. Been too busy trying to get 2.5.0-rc5 to run on my M1 MacBook Air. >>> ;-) > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
