Hey hey, On 19 Jan 2022, at 04:01, Thiago Macieira <[email protected]<mailto:[email protected]>> wrote:
3) add a way to have multi-arch glibc-based Linux builds If we go down this road I ask that we align both the porcelain and plumbing (configure, build system, C++ APIs, etc) . We already have universal builds on macOS and iOS done one way, and multi-arch/abi on Android another way. Let’s not add a third slightly different way, but instead use the opportunity to pay off some of the technical debts in this area. 4) up the defaults from where they are today Question: - iOS simulator builds are x86, but currently only SSE2. Does anyone know if raising to SSE4, which *ALL* 64-bit Mac machines support, would be a problem? That should be fine. The only reason SSE2 was chosen at the time was to ensure we built the draw helpers for the simulator build. 6) for macOS, raise the minimum to v3 (x86_64h) macOS has supported an extra architecture called "x86_64h" for some time (the "h" stands for "haswell"). Apple ceased offering macOS updates to processors without AVX2 back with the Mojave release (10.14) in 2018. Since that's the minimum version we require for Qt, it means all Intel-based Macs Qt can run on also support this sub-arch. One data point here, that I don’t know is worth anything, is that on macOS 12 at least, none of the system binaries in /bin or /sbin are x86_64h, they are all x86_64+arm64e (arm64e reserved for Apple for now). On the other hand, the dyld shared cache (of all the system frameworks) provides x86_64h: ❯ ls /System/Library/dyld/ aot_shared_cache.0 aot_shared_cache.3 aot_shared_cache.t8027.2 dyld_shared_cache_arm64e.1 dyld_shared_cache_x86_64.1 dyld_shared_cache_x86_64.map dyld_shared_cache_x86_64h.2 aot_shared_cache.1 aot_shared_cache.t8027.0 aot_shared_cache.t8027.3 dyld_shared_cache_arm64e.map dyld_shared_cache_x86_64.2 dyld_shared_cache_x86_64h dyld_shared_cache_x86_64h.3 aot_shared_cache.2 aot_shared_cache.t8027.1 dyld_shared_cache_arm64e dyld_shared_cache_x86_64 dyld_shared_cache_x86_64.3 dyld_shared_cache_x86_64h.1 dyld_shared_cache_x86_64h.map It might also need some more work than just changing our default. E.g, changing the arch in a simple Xcode project gives: The run destination My Mac is not valid for Running the scheme 'rasterwindow’. My Mac doesn’t support any of rasterwindow.app’s architectures. You can set rasterwindow.app’s Architectures build setting to Standard Architectures to support My Mac. This is on a 2019 MBP Xcode’s ARCH_STANDARD build variable is [x86_64, arm64]. The same problem persists after updating VALID_ARCHS from the default [arm64 arm64e i386 x86_64] to [arm64 arm64e i386 x86_64 x86_64h]. I'd like to do this for all libraries and by default on binaries from qt.io<http://qt.io>. However, I understand the ARM translation application cannot deal with the AVX instructions, so it would fail to run our default binaries for the applications that couldn't rebuild as ARM. Is it acceptable to require those application developers to rebuild Qt from source? I believe we detect that situation at runtime and explicitly turn off AVX support, so we wouldn’t be hitting any of those AVX code paths, if I understand things correctly? Cheers, Tor Arne
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
