use x86_64h for macos targets >= 12.0#1461
Open
tsteven4 wants to merge 3 commits into
Open
Conversation
Collaborator
Author
|
This was suggested at godotengine/godot-proposals#11150 |
Collaborator
Author
|
@robertlipe can you confirm macos >= 12.0 requires haswell on intel cpus? |
Collaborator
Author
|
The above reasoning makes one question why Qt 6.10.0 even supports x86_64 (actually >= 6.8.0). |
Collaborator
Author
|
This suggests pre-haswell cpus were dropped with ventura, not monterey. |
Collaborator
Author
|
It seems like Qt distributes macos binaries for x86_64 and arm64 and not x86_64h. From 6.10.0-0-202509051021qtbase-MacOS-MacOS_15-Clang-MacOS-MacOS_15-X86_64-ARM64.7z we see X86_64 ALL and ARM64 ALL. OTOH if we build for x86_64 and x86_64h we see that the cpusubtype distinguishes the two: |
Collaborator
|
I think we have an opportunity to roll this in substantially. Godot is
going to care about microarches at a level way below us.
Setting aside for a moment how we spell this in code, our stated goal has
always been "current and one back". MacOS give us a pretty tight cadence on
releases and Tahoe was, uh, almost 48 hours ago. :-) So just writing out
the rules as I understand them, showing my work:
- Tahoe (the version after 15, but "26") is supernew and will be the
final version that supports Intel of any kind.
- Sequoia, 15
- Sonoma, 14, is still getting security updates, but drops hardware
support for > 2017 machines, leaving 2017's iMac Pro as the oldest. It has
a Xeon W with Skylake. Skylake > Haswell. So anything running Sonoma is >
Haswell.
- Ventura, 13, is "unsupported as of Sept 15, 2025". It "drops support
for Macs release in 2015 and 2016"
- Monterey, 12, "Drops support for Macs released from 2013 to 2014".
- Big Sur, 11, "Drops support for Macs released from 2012 to early 2013."
- Catalina, 10, is 10.15
So by the book, if we were to make a release today, we *could* draw the
line at Sequoia. That's a little hyperactive, I think. Sonoma is still
getting security updates, so I don't think that's an unreasonable floor. If
a $3T company doesn't support Ventura, I don't think Id feel bad about us
not supporting it.
There's some fuzziness around OLCP and 'hopped up' patches of newer OS
versions running on older hardware. I think we officially don't care about
such configurations even though I'd be audience for such things myself. My
2012 iMac with Catalina would still be a viable machine, but it would be
irresponsible from a security view to depend upon it. Other than the look
of the little traffic lights that decorate each window, I don't think I've
been able to tell them apart since about Snow Leopard or so. New releases
are bundles of new applications (Safari, mail, contacts, etc.) that I
mostly don't use anyway.
Sonoma is the oldest still getting security releases and the oldest that
Apple cares about. That seems a pretty defensible baseline. That gets us to
hardware >= 2018 plus the 2017 iMac Pro which, honestly, wasn't a volume
machine and I think the kind of people that bought an iMac Pro have already
moved on, so they're hand-me-downs and really not part of our typical user
base. Haswell (tick) was 2013-2015. Broadwell (tock) was 2015-2017.
So if I repeat your own words back slowly and diagramming the sentences we
we go, we get:
I believe macOS 12.0 (which is below what we care about) or later does not
run on pre-Haswell Intel CPUs.
We care about >= 14, sonoma. macOS Sonoma supports Intel processors that
are 8th generation Coffee Lake/Amber Lake or newer, as well as all Apple
silicon Macs. There are reports of Sonoma workign with some Broadwell
hackintoshes via OLCP, but Broadwell was almost
<https://en.wikipedia.org/wiki/List_of_Mac_models_grouped_by_CPU_type#Broadwell>
ignored by Apple; it was clearly during their love withdrawal phase with
Intel. Turning this equation around, canceling out the common denominators,
I think this means any supoprted MacOS configuration that we care about has
"lake" in the name and "cove" in the uarch.
So (deep breath) yes, where x86_64h is a thing, which includes the XCode
min ABI, I think we can rely on that Notably bit counts and AVX2 but not
512. Apple's binary standards and LLVM are in a positoin to be able to
distinguish these things beyond the turn of the century
Opteron/Hammer/Athlon definitions of amd64. MacOS is in a position to
update names over time. They don't have to care if a Tahoe binary/library
will run on a Core 2; they can walk the definition forward over time.
I agree with your read of https://doc.qt.io/qt-6/macos.html that they're
probably coasting on Haswell-not x86_64 just because on MacOS the
definitions are stronger than on systems running on an arbitrary 20 y/o
clone motherboard.
For your PR itself, I think we're in the interesting situation of Qt
supporting more cases than we probably care about.
DEPLOY_TARGET="13.0"
could probably go to 14. If that was sketched up a couple of quarters ago,
13 would have been a sensible choice. I don't think we really gain anything
by turning the screws more aggressively. It's not like we're getting
hammered in support traffic. It's pretty hard to imagine any case at this
point involving me needing to virtualize a guest install on a borrowed x86
system; Rosetta is freaking awesome. We have a pretty clear sunset date for
the intel builds so this wil reference count to zero soon.
Those Qt 6.0 and 5.12 cases could be dropped.
So, with all that researched and thought through, I agree with this patch
but note that it's even more generous on bringing up the tail than I think
we officially need need to be.
I don't miss the days of being redbook disclosed by Intel, either. Holy cow
the lines are complicated these days. I'll also admit this is about the
point where I quit tracking x86 at all. I can no longer play x86 trivial
pursuit. I'm done with it. I've served my sentence.
…On Tue, Sep 16, 2025 at 8:07 PM tsteven4 ***@***.***> wrote:
*tsteven4* left a comment (GPSBabel/gpsbabel#1461)
<#1461 (comment)>
It seems like Qt distributes macos binaries for x86_64 and arm64 and not
x86_64h. From
6.10.0-0-202509051021qtbase-MacOS-MacOS_15-Clang-MacOS-MacOS_15-X86_64-ARM64.7z
we see X86_64 ALL and ARM64 ALL.
otool -hv -arch all QtCore
QtCore (architecture x86_64):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 29 4256 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS MH_HAS_TLV_DESCRIPTORS APP_EXTENSION_SAFE
QtCore (architecture arm64):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 ARM64 ALL 0x00 DYLIB 29 4416 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS MH_HAS_TLV_DESCRIPTORS APP_EXTENSION_SAFE
OTOH if we build for x86_64 and x86_64h we see that the cpusubtype
distinguishes the two:
otool -hv -arch all gpsbabel
gpsbabel (architecture x86_64):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 EXECUTE 27 2904 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE MH_HAS_TLV_DESCRIPTORS
gpsbabel (architecture x86_64h):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 Haswell 0x00 EXECUTE 27 2904 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE MH_HAS_TLV_DESCRIPTORS
—
Reply to this email directly, view it on GitHub
<#1461 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD2Q5OQW46VJ4622D5D3TCX4LAVCNFSM6AAAAACGWIDYK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMBQHAZTEMJZGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
robertlipe
approved these changes
Sep 17, 2025
Collaborator
Author
|
@robertlipe thanks for you comments. Regarding the DEPLOY_TARGETS, I have been matching the minimum for the corresponding version of Qt. I don't see a benefit to a stricter requirement that what the Qt version we are using imposes. I am cooling off on x86_64h given that the distributed Qt libraries aren't available for it. I think the action runs here shows we could build for x86_64h and link with x86_64 Qt libs, but I am not sure it's worth it. We will have to pick versions of Qt for an upcoming release. I have been working on using the yet to be released 6.10.0 for Windows arm64 (WoA) builds (miurahr/aqtinstall#941, https://github.com/tsteven4/gpsbabel/tree/qt610test1). 6.10.0 is the first Qt release with QtWebEngine for WoA. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I believe macOS 12.0 or later does not run on pre-Haswell Intel CPUs. So when our minimum target is >= 12.0 we should use x86_64h instead of x86_64.