[macOS] Use arm64 snapshot in arm64 App.framework (#100504)
Previously, https://github.com/flutter/flutter/pull/100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: https://github.com/flutter/flutter/issues/100348
Showing
Please register or sign in to comment