macOS - Apple Silicon - universal binary

[Andy Robinson]

The notes for wxWidgets 3.1.4 say "wxOSX port now supports the latest
macOS 11 on ARM hardware".

I presume it should be possible to build universal binary for x64/arm64
on both Intel & ARM machines? (I don't have an ARM machine at the moment).

But how is it done? "configure" has an --enable-universal_binary option
but this is not the right sort of universal binary, it means i386/x64.

I found these pages, which all seem rather out of date:

https://wiki.wxwidgets.org/WxMac-specific_topics
(latest macOS mentioned is 10.7)

https://www.wxwidgets.org/docs/faq/osx/
(refers to wxWidgets 2.8.x)

https://wiki.wxwidgets.org/Development:_wxMac
(latest macOS mentioned is 10.6)

Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com

[Vadim Zeitlin]

On Wed, 4 Nov 2020 11:44:41 +0000 Andy Robinson wrote:

AR> The notes for wxWidgets 3.1.4 say "wxOSX port now supports the latest
AR> macOS 11 on ARM hardware".
AR>
AR> I presume it should be possible to build universal binary for x64/arm64
AR> on both Intel & ARM machines? (I don't have an ARM machine at the moment).

Me neither, so I can't check it myself.

AR> But how is it done? "configure" has an --enable-universal_binary option
AR> but this is not the right sort of universal binary, it means i386/x64.

You can give an argument to this option with the list of the architectures
to use, so --enable-universal_binary=arm,x86_64 should work and if it
doesn't, it should be fixed.

We should probably also consider changing the default from i386,x86_64 to
arm,x86_64 for 3.2.0 release, as this seems more useful going forward.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Stefan Csomor]

Hi

I presume it should be possible to build universal binary for x64/arm64
on both Intel & ARM machines? (I don't have an ARM machine at the moment).

yes, you need the latest Xcode 12 - a build that is capable of producing code for ARM aka Apple Silicon - whether It's running under Intel or Apple Silicon

But how is it done? "configure" has an --enable-universal_binary option
but this is not the right sort of universal binary, it means i386/x64.

For Apple Silicon up to now I've only used simple builds with

-arch arm64

But I'm now running a --enable-universal_binary=arm64,x86_64 to test

Best,

Stefan

[Anil Kumar]

Adding to Stephen,

It is not Xcode12, try with Xcode 12 Beta3 at present. Please check the information given on the download page, it clearly says Xcode for Intel and Apple Silicon.

Simply open the wxcocoa.xcodeproj in Xcode 12 beta 3. By default Xcode selects the  "STANDARD_ARCHS" which is arm64 + x86_64. If it is not selected please select it manually.

Build and you are done. Can verify the binaries using lipo -info command. Anyway, you will see binaries size is almost double (45 MB)  than the regular 22MB.

Thanks,

Anil

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/AFCE4330-4D92-425A-A842-6FF424116B7C%40advancedconcepts.ch.

[Andy Robinson]

I'm using
macOS: 11.0.1 Beta (20B5012d)
Xcode: 12.2 beta 3 (12B5035g)

and I've just built the library with
configure --with-macosx-version-min=11.0
--enable-universal_binary=arm64,x86_64

and I can compile & run the minimal sample on Intel with no problems. I
look forward to trying it on ARM when I have one.

[Stefan Csomor]

Hi

• It is not Xcode12, try with Xcode 12 Beta3 at present. Please check the information given on the download page, it clearly says Xcode for Intel and Apple Silicon.

 

Yes, thanks, sorry for not being clear, I meant to say, that you should pick the latest Xcode 12 build that is capable of building for both …

 

And yes, I’m using Xcode builds for my own apps, that’s where things come easily 😉 but Andy was asking about command line builds, so we must make sure that this also works, including code-signing instructions, as on Big Sur on Apple Silicon only signed binaries can be executed, no workaround possible.

 

Best,

 

Stefan

[Andy Robinson]

On 04/11/2020 14:25, Stefan Csomor wrote:
> And yes, I’m using Xcode builds for my own apps, that’s where things
> come easily 😉but Andy was asking about command line builds, so we must
> make sure that this also works, including code-signing instructions, as
> on Big Sur on Apple Silicon only signed binaries can be executed, no
> workaround possible.

That's interesting - I didn't know that no workaround was possible.

Speaking for myself, I do the signing and notarizing (and everything
else) from the command line using a makefile. The reason why I work this
way is that I build for Windows, Mac & Linux so I don't really want to
use 3 different IDEs with the possibility of things getting out of sync
between them. Instead I have all the sources on the Linux machine and I
have a script which generates a folder full full of files for each OS,
including a makefile. I copy these folders each to the relevant build
machine and type "make". This guarantees consistency - e.g. the program
version number appears in only one place. The script I mentioned copies
it into all the other places it needs to be for each OS.

Andy

[Anil Kumar]

" Speaking for myself, I do the signing and notarizing (and everything
else) from the command line using a makefile. The reason why I work this
way is that I build for Windows, Mac & Linux so I don't really want to
use 3 different IDEs with the possibility of things getting out of sync
between them. Instead I have all the sources on the Linux machine and I
have a script which generates a folder full full of files for each OS,
including a makefile. I copy these folders each to the relevant build
machine and type "make". This guarantees consistency - e.g. the program
version number appears in only one place. The script I mentioned copies
it into all the other places it needs to be for each OS"

Thank you. useful to me at least.  🤗

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/d3f06d5f-6360-9274-9bcc-5c6d9fe90caf%40seventhstring.com.

[Andy Robinson]

On 04/11/2020 14:25, Stefan Csomor wrote:

> on Big Sur on Apple Silicon only signed binaries can be executed, no
> workaround possible.

I now have a Mac Mini with M1 processor, I'm building wx on Intel as
universal binary, and building the minimal sample also on the Intel
machine, with the following edit so I can be sure which code is running:

#ifdef __x86_64__
MyFrame *frame = new MyFrame("Minimal wxWidgets App INTEL");
#else // __arm__
MyFrame *frame = new MyFrame("Minimal wxWidgets App APPLE SILICON");
#endif

I find that I can copy the app over to the ARM machine and it runs just
fine (and says "Minimal wxWidgets App APPLE SILICON").

So I'm puzzled by what you say about no workaround?

I also find I can install and use the GStreamer Mac framework on the ARM
machine using the same technique that I have always used. I download the
pkg installer, I can't run this directly because it isn't signed, but I
copy it over the network to a Linux machine and then copy back to the
Mac, and then I can install and use it.

Unfortunately I cannot yet build my app universal because it uses
GStreamer and that is not (yet) universal. But I find that my
Intel-built app, and GStreamer, both work fine on Rosetta so that's ok
for now.

I mention this in case others may be interested in these results.

[Vadim Zeitlin]

On Wed, 18 Nov 2020 14:06:14 +0000 Andy Robinson wrote:

AR> On 04/11/2020 14:25, Stefan Csomor wrote:
AR> > on Big Sur on Apple Silicon only signed binaries can be executed, no
AR> > workaround possible.
AR>
AR> I now have a Mac Mini with M1 processor, I'm building wx on Intel as
AR> universal binary, and building the minimal sample also on the Intel
AR> machine, with the following edit so I can be sure which code is running:
AR>
AR> #ifdef __x86_64__
AR> MyFrame *frame = new MyFrame("Minimal wxWidgets App INTEL");
AR> #else // __arm__
AR> MyFrame *frame = new MyFrame("Minimal wxWidgets App APPLE SILICON");
AR> #endif
AR>
AR> I find that I can copy the app over to the ARM machine and it runs just
AR> fine (and says "Minimal wxWidgets App APPLE SILICON").
AR>
AR> So I'm puzzled by what you say about no workaround?

I always thought it only applied to the downloaded files, not something
you built on your own machine, or copied to it in some other way. I hope
even Apple doesn't require signing each and every binary you build. Yet,
anyhow...

AR> I also find I can install and use the GStreamer Mac framework on the ARM
AR> machine using the same technique that I have always used. I download the
AR> pkg installer, I can't run this directly because it isn't signed, but I
AR> copy it over the network to a Linux machine and then copy back to the
AR> Mac, and then I can install and use it.

Unfortunately I don't think this is an appropriate workaround to suggest
to an average Mac user. So in practice the installer still has to be signed
to allow people to run your software.

AR> Unfortunately I cannot yet build my app universal because it uses
AR> GStreamer and that is not (yet) universal. But I find that my
AR> Intel-built app, and GStreamer, both work fine on Rosetta so that's ok
AR> for now.

Does it really run as fast or even faster than it ran natively on old
Intel Macs?

AR> I mention this in case others may be interested in these results.

I definitely am, thanks for sharing!

[Julian Smart]

Hi,

According to this page:

https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/
<https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/>

you only need to do add-hoc signing, so just an extra line in your makefile:

codesign -s - name.app

I've done this and I'm (slightly anxiously) waiting to hear from a
customer whether my universal binary runs on the M1:

http://www.jutoh.com/Jutoh-3.03-beta2-IntelARM.dmg
<http://www.jutoh.com/Jutoh-3.03-beta2-IntelARM.dmg>

The M1 seems pretty exciting - I can imagine a lot of Windows users
being seduced by this hardware (especially given Windows 10 is so crashy
these days).

Regards,

Julian

[Andy Robinson]

On 19/11/2020 12:13, Vadim Zeitlin wrote:

> Unfortunately I don't think this is an appropriate workaround to suggest
> to an average Mac user. So in practice the installer still has to be signed
> to allow people to run your software.

Yes indeed. I wrote to the GStreamer discussion group 3 or 4 years ago
to say that it seems strange to write such brilliant software and then
distribute it in a way that most people cannot install. No one even
replied. My solution is that I prepared a cut-down version (removing
plugins that my app doesn't need) and signed it myself, for the benefit
of my users. The same on Windows.

> Does it really run as fast or even faster than it ran natively on old
> Intel Macs?

No doubt it depends on the nature of the computation but I have just
tried converting a video to a different format (with GStreamer) and the
result is:

Intel 2019 iMac, Big Sur, 3.7GHz 6-core i5 processor: 82 seconds

ARM 2020 Mac Mini, Big Sur, M1 processor, the same Intel code running on
Rosetta: 88 seconds.

So, slightly slower but not much difference.

[Vadim Zeitlin]

On Thu, 19 Nov 2020 12:54:02 +0000 Julian Smart wrote:

JS> According to this page:
JS>
JS> https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/
JS> <https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/>
JS>
JS> you only need to do add-hoc signing, so just an extra line in your makefile:
JS>
JS> codesign -s - name.app

Thanks, this is good to know. But even after reading the article above, I
still don't understand why is it necessary, i.e. what possible advantage
does it provide. The argument that it ensures that the application is not
modified seems completely risible on the surface: accidental modification
is extremely unlikely to happen (i.e. basically never does) while any
malware modifying the executable intentionally would apparently be able to
just sign the new, modified executable. So am I missing something here or
is the requirement for all executables to have a signature really
completely devoid of any sense? Other than as a stepping stone to imposing
even more drastic, iOS-like, controls on Mac applications, that is.

JS> The M1 seems pretty exciting - I can imagine a lot of Windows users
JS> being seduced by this hardware (especially given Windows 10 is so crashy
JS> these days).

Considering how fast it runs (thanks for the benchmark, Andy!), it does
seem appealing and the next model might be very interesting indeed.

Regards,

[Andy Robinson]

On Thu, 19 Nov 2020 12:54:02 +0000 Julian Smart wrote:
JS> According to this page:

JS> you only need to do add-hoc signing, so just an extra line in your
makefile:

I don't know what happens if you distribute with ad-hoc signing but I do
know that for $79 (or £79? can't remember) per year you can join the
Apple Developer Network and get a Developer ID of your own, with which
you can sign your app and get it notarized by Apple.

[Julian Smart]

On 20/11/2020 10:22, Andy Robinson wrote:
> On Thu, 19 Nov 2020 12:54:02 +0000 Julian Smart wrote:
> JS> According to this page:
> JS> you only need to do add-hoc signing, so just an extra line in your
> makefile:
> I don't know what happens if you distribute with ad-hoc signing but I
> do know that for $79 (or £79? can't remember) per year you can join
> the Apple Developer Network and get a Developer ID of your own, with
> which you can sign your app and get it notarized by Apple.

Yes, I admit it is time to overcome my partly ideological objections to
jumping through Apple's hoops and get with the programme. It helps that
Apple now have more interesting hardware.

Regards,

Julian