Hi Brian, The builds I provide are signed properly to run on other systems. 2.6.0rc1 is here:
https://www.dropbox.com/s/dj7dx4swnh1pnas/wsjtx.app.zip?dl=0 Also I posted some instructions for building M1 here: http://folabs.com/building-wsjt-x-apple-m1.html best, alex > On Jul 3, 2022, at 12:12 PM, Brian Moran via wsjt-devel > <wsjt-devel@lists.sourceforge.net> wrote: > > > Hi Alex and and Olof; I too have been building M1-specific binaries (for > 2.6.0 rc-1). > > There certainly are some caveats in building specifically for M1 chips at > this time, starting with specifying some of the CMake variables required: > > CMAKE_OSX_ARCHITECTURES -> arm64 (this chooses M1-specific binary generation) > CMAKE_OSX_DEPLOYMENT_TARGET -> 12.0 (a good minimum for M1 code generation -- > the 10.2 default doesn't support M1, leads to linker errors) > > These variables must be configured in TWO places, both in the top-level build > directory, as well as in the build's wsjtx-build location. > > Then, of course, one must have the dependencies for compiling and linking. > One dependency is the M1-specific Qt libraries to link against; one way to > install those is via a package manager such as Homebrew > (https://formulae.brew.sh/formula/qt@5). > > Some other current issues in building from the source tarball: > If one is building the "install" target, the generated App gets put in an > inconvenient location > If one is building the .DMG ("package" target), then all of the binaries in > the DMG must be re-signed with a locally trusted certificate, even to install > and test the DMG locally. > Building hamlib in conjunction with wsjtx (from the source tarball) can > require that ./configure be run again in the hamlib src directory to > configure platform-specific symbols > > Alex, you might find that if you provide the arm64 binary to someone, you'll > also need to get the receiver to re-sign the binary so it runs on their > system -- native M1 binaries are a little more locked down than Intel-code > binaries. To avoid that annoyance, there would need to be signed > distributions available, or a willingness for the recipient of the binaries > to install the Xcode code signing tool to re-sign the binaries. > > Since the Intel-compiled binaries do run on M1 Macs, the need isn't as acute > to make M1-specific binaries available... yet. > > I'd love to hear from others that are building M1-specific arm64 binaries > > -Brian N9ADG > > > > > >> On Sun, Jul 3, 2022 at 11:18 AM Olof Johansson via wsjt-devel >> <wsjt-devel@lists.sourceforge.net> wrote: >> Hi Alex, >> >> Do you happen to have your modifications on a public git repo somewhere? I >> would like to rebuild from sources locally, if possible. >> >> Also (to the maintainers): what's holding this up from being merged into the >> upstream repo? Would be nice to see it making its way in, and I'd love to >> see official m1 binaries at some point. >> >> >> -Olof >> >> >>> On Wed, Mar 30, 2022 at 9:27 AM Alex Lelievre via wsjt-devel >>> <wsjt-devel@lists.sourceforge.net> wrote: >>> Hi there, >>> >>> I’ve been testing my native build of WSJTX 2.5.4 on Apple M1 now for quite >>> some time and it works great. If anyone wants to give it a shot, I can >>> post my binary that you can drag and drop into your current install. Let >>> me know if there is any interest. >>> >>> alex >>> K6LOT >>> > _______________________________________________ > 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
