Min requirements for universal builds

[Robin Dunn]

Hi all,

I've been away from the wx world for a long while due to job and life changes, but I've started working on getting caught up again. Today's task is to get macOS universal binaries working.

I've updated one of my build machines to macOS 10.15 Catalina, and Xcode 12.2, and also tried command line tools 12.4. It seems that the machine is not able to be upgraded beyond Catalina, probably due to its age.

Should I be able to build universal binaries with this configuration?

Trying to build a simple C program gives the following error, and running wxWidgets' configure with --enable-universal_binary=arm64,x86_64 runs into the same problem when testing the ability to build C++ programs and fails after just a dozen or so lines of output.

gcc -arch x86_64 -arch arm64 -x c simple.c
ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd, missing required architecture arm64 in file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

So it looks like the libs in the default SDK don't have the arm64 architecture included. I see that there is a 11.1 SDK installed and forcing its use is enabling the simple compile to succeed.

> gcc -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk  -arch x86_64 -arch arm64 -x c simple.c
> file a.out
a.out: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
a.out (for architecture x86_64):    Mach-O 64-bit executable x86_64
a.out (for architecture arm64):    Mach-O 64-bit executable arm64

Is this the right way to proceed?

Thanks,
Robin

[Lauri Nurmi]

Robin Dunn kirjoitti 26.11.2021 klo 0:00:

Hi all,

I've been away from the wx world for a long while due to job and life changes, but I've started working on getting caught up again. Today's task is to get macOS universal binaries working.

I've updated one of my build machines to macOS 10.15 Catalina, and Xcode 12.2, and also tried command line tools 12.4. It seems that the machine is not able to be upgraded beyond Catalina, probably due to its age.

Should I be able to build universal binaries with this configuration?

I have macOS Catalina and Xcode 12.4 (the last version that runs on Catalina), and I am able to build universal binaries without specifying which SDK to use.

gcc -arch x86_64 -arch arm64 -x c simple.c

This command does work for me, and creates a universal binary.

[Vadim Zeitlin]

On Thu, 25 Nov 2021 14:00:02 -0800 Robin Dunn wrote:

RD> I've been away from the wx world for a long while due to job and life
RD> changes, but I've started working on getting caught up again.

Hi and glad to see you back! And hope that all the changes were for the
better...

RD> Today's task is to get macOS universal binaries working.

FWIW I didn't have any particular problems with this, but I've only done
it on my ARM Mac mini which was under macOS 11 at first and is under 12
now. If you can, I strongly recommend getting one as building on it is
*much* faster.

RD> I've updated one of my build machines to macOS 10.15 Catalina, and Xcode
RD> 12.2, and also tried command line tools 12.4. It seems that the machine
RD> is not able to be upgraded beyond Catalina, probably due to its age.
RD>
RD> Should I be able to build universal binaries with this configuration?

I think you should be, I'm pretty sure that you're not _required_ to use
ARM Mac to build for one... But it looks like you just don't have the right
SDK and unfortunately I don't know where/how to get the right one exactly.

RD> Trying to build a simple C program gives the following error, and
RD> running wxWidgets' configure with --enable-universal_binary=arm64,x86_64
RD> runs into the same problem when testing the ability to build C++
RD> programs and fails after just a dozen or so lines of output.
RD>
RD> gcc -arch x86_64 -arch arm64 -x c simple.c
RD> ld: warning: ignoring file
RD> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd,
RD> missing required architecture arm64 in file
RD> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd
RD> ld: dynamic main executables must link with libSystem.dylib for
RD> architecture arm64
RD> clang: error: linker command failed with exit code 1 (use -v to see
RD> invocation)

As .tbd are simple text files, you should be able to trivially confirm
that this one only uses x86_64 arch and, maybe more interestingly, be able
to easily check if the other SDKs that you have support ARM.

BTW, I also think that it's better to use SDK included in Xcode if you
have it installed. Separate command line tools are supposed to work too,
but IME Xcode works better and I always end up installing it, due to one
problem with the command tools or another, even though I don't really use
it.

Good luck!
VZ

[Stefan Csomor]

Hi Robin

 

Welcome back 😊 great to read from you!

> I've updated one of my build machines to macOS 10.15 Catalina, and Xcode 12.2, and also tried command line tools 12.4. It seems that the machine is not able to be upgraded beyond Catalina, probably due to its age.

> Should I be able to build universal binaries with this configuration?

You need Xcode 12.2 and at least a macOS 11 SDK

 

Is this the right way to proceed?

As I’m always building universal binaries using the Xcode projects, I’m not really qualified on that, but IIRC we had a configure option --with-macosx-sdk, so I’d think with that you should be able to build under Catalina on the command line

(and the M1 machines are really quite fast, the building experience on my MacBook Pro has changed considerably from the 2015 to the 2021 model 😉 so I can really recommend the switch to M1, already the smallest mini is very capable …)

Best,

Stefan

 

[Robin Dunn]

Thanks guys. I guess I was just surprised that the default SDK chosen didn't support universal builds, and I thought I was probably doing something wrong.

Robin


Stefan Csomor wrote on 11/26/21 9:47 AM:

--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/19D9C71A-715C-420C-9BEF-930106048FAB%40advancedconcepts.ch.

[Lauri Nurmi]

Robin Dunn kirjoitti 27.11.2021 klo 7:05:
> Thanks guys. I guess I was just surprised that the default SDK chosen
> didn't support universal builds, and I thought I was probably doing
> something wrong.

As I wrote earlier, (but maybe nobody saw it), the default SDK *does*
support universal builds with Xcode 12.4 at least. There is no need to
explicitly specify SDK version on command line.

[Stefan Csomor]

Hi

Am 27.11.21, 15:23 schrieb "wx-...@googlegroups.com im Auftrag von Lauri Nurmi" <wx-...@googlegroups.com im Auftrag von lan...@iki.fi>:

I did see it __ and tried to think about the differences between your setup and Robin's ...

Because he says

gcc -arch x86_64 -arch arm64 -x c simple.c

gives him

ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd, missing required architecture arm64 in file

which IMHO does not indicate that the default SDK in his case support arm64, I really doubt that there is some arm64 in 10.15sdk. And it shows that he is using command line tools, perhaps this is relevant, I don't

so I guess it depends which Xcode tools are currently the default or rather what SDK. So I'd assume

xcrun --show-sdk-path

is returning /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk for him, then the next question would be what that alias is now pointing to. I'd assume it is a 10.15 ... while in your case it is either directly pointing into your Xcode 12 or the alias of your command line tools' SDK is correctly pointing at a 11.X ...

Best,

Stefan

[Robin Dunn]

Stefan Csomor wrote on 11/27/21 7:04 AM:

> Hi
>
> Am 27.11.21, 15:23 schrieb "wx-...@googlegroups.com im Auftrag von Lauri Nurmi" <wx-...@googlegroups.com im Auftrag von lan...@iki.fi>:
>
> Robin Dunn kirjoitti 27.11.2021 klo 7:05:
> > Thanks guys. I guess I was just surprised that the default SDK chosen

> ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd, missing required architecture arm64 in file
>
> which IMHO does not indicate that the default SDK in his case support arm64, I really doubt that there is some arm64 in 10.15sdk. And it shows that he is using command line tools, perhaps this is relevant, I don't
>
> so I guess it depends which Xcode tools are currently the default or rather what SDK. So I'd assume
>
> xcrun --show-sdk-path
>
> is returning /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk for him, then the next question would be what that alias is now pointing to. I'd assume it is a 10.15 ... while in your case it is either directly pointing into your Xcode 12 or the alias of your command line tools' SDK is correctly pointing at a 11.X ...

Yes. More or less. When I was using Command Line Tools for Xcode 12.4 it
included both the 10.15 and the 11.1 SDKs, and the default was
sym-linked to the 11.1 SDK folder, although the 10.15 was still chosen
by default for some reason. I then removed the CLT and installed Xcode
12.4, and it only includes the 11.1 SDK so I think that it will work as
expected now, although I haven't retried my simple test yet to verify.

BTW, if using Homebrew, be aware that their ar and/or ranlib will drop
the arm64 part of the .o files. (At least on Catalina.) That was fun to
track down.

Thanks,
Robin

[Scott Talbert]

Hey Robin,

It would be quite helpful if you could re-enable the nightly wxPython
builds (or perhaps they broke?), but perhaps that's what you're in the
process of doing already? Especially because there are no wheels yet for
Python 3.10.

Thanks,
Scott

[Robin Dunn]

Scott Talbert wrote on 12/2/21 9:10 AM:

>
> It would be quite helpful if you could re-enable the nightly wxPython
> builds (or perhaps they broke?), but perhaps that's what you're in the
> process of doing already?  Especially because there are no wheels yet
> for Python 3.10.

Yep, that's on my TODO list.


Robin