8000 Build arm64 during Mac Host Engine build · Issue #84453 · flutter/flutter · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Build arm64 during Mac Host Engine build #84453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Tracked by #60118
jmagman opened this issue Jun 11, 2021 · 27 comments
Closed
Tracked by #60118

Build arm64 during Mac Host Engine build #84453

jmagman opened this issue Jun 11, 2021 · 27 comments
Labels
engine flutter/engine repository. See also e: labels. P2 Important issues not at the top of the work list team Infra upgrades, team productivity, code health, technical debt. See also team: labels. team-infra Owned by Infrastructure team

Comments

@jmagman
Copy link
Member
jmagman commented Jun 11, 2021

Dart side is looking good: https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-mac-release-arm64

Add configuration to build the ARM macOS host engine.
@jmagman jmagman added team Infra upgrades, team productivity, code health, technical debt. See also team: labels. engine flutter/engine repository. See also e: labels. team-infra Owned by Infrastructure team P2 Important issues not at the top of the work list labels Jun 11, 2021
@jmagman jmagman mentioned this issue Jun 11, 2021
Closed
35 tasks
@zanderso
Copy link
Member

/cc @gw280

@jmagman jmagman mentioned this issue Jun 14, 2021
Closed
@godofredoc
Copy link
Contributor

@jmagman @gw280 Is this blocked on something from infra?

@jmagman
Copy link
Member Author
jmagman commented Aug 5, 2021

I don't think it's blocked on anything from the infra team.
It will likely involve updating engine and buildroot build rules, as well as recipe changes like https://flutter-review.googlesource.com/c/recipes/+/14780.

@jmagman jmagman mentioned this issue Aug 23, 2021
Closed
@jmagman
Copy link
Member Author
jmagman commented Aug 23, 2021

flutter_tester Rosetta issue: #88106

@zanderso
Copy link
Member

It looks like we'll need a newer MacOS SDK to target arm64 from the Engine builder.

https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/zra_google.com/c1ca466e97044968507388a4dcf8455c97a2c04a06c9e2611114075a9070c467/+/build.proto?server=chromium-swarm.appspot.com

@godofredoc I see that it's possible to use a newer SDK from the devicelab builders, but not sure what the right thing is to do from the Engine builder.

@zanderso zanderso changed the title Build ARM during Mac Host Engine build Build arm64 during Mac Host Engine build Oct 10, 2021
@jmagman
Copy link
Member Author
jmagman commented Oct 11, 2021

https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/zra_google.com/c1ca466e97044968507388a4dcf8455c97a2c04a06c9e2611114075a9070c467/+/build.proto?server=chromium-swarm.appspot.com

@zanderso That link isn't loading for me, @CaseyHillers suggests a LUCI outage may have been unable to write the initial request, and you'll need to retry it? But you ran it 23 hours ago and I assume you saw the logs based on your comment.

If you can load it, can you just upload the logs in question? Or re-run it?

@zanderso
Copy link
Member

Here is a re-run https://ci.chromium.org/swarming/task/5689a49b6955b710?server=chromium-swarm.appspot.com

@godofredoc
Copy link
Contributor
godofredoc commented Oct 11, 2021 •
edited
Loading

Devicelab tests are currently using: 12c33

Can you please add the following to your led command?

led edit -pa xcode=12c33 | led edit -pa $flutter/osx_sdk='{"sdk_version": "12c33" }'
8000

@jmagman
Copy link
Member Author
jmagman commented Oct 11, 2021

The builders can't use 12c33 due to bitcode issues, it needs to stay on the version of clang associated with the lowest version supported by the flutter_tool.
We need to add macOS 11 (Big Sur) SDK to the existing 12a7209 cipd package.

@jmagman
Copy link
Member Author
jmagman commented Oct 11, 2021

We need to add macOS 11 (Big Sur) SDK to the existing 12a7209 cipd package.

I'll work on that now.

@zanderso
Copy link
Member
zanderso commented Oct 11, 2021 •
edited
Loading

Devicelab tests are currently using: 12c33

Can you please add the following to your led command?

led edit -pa xcode=12c33 | led edit -pa $flutter/osx_sdk='{"sdk_version": "12c33" }'

Trying this now. For posterity, I needed a \ before the $ in \$flutter/osx_sdk=...

https://ci.chromium.org/swarming/task/568a1f2b9d4a4710?server=chromium-swarm.appspot.com

@zanderso
Copy link
Member

The build here failed how I was expecting.

../../third_party/libcxx/include/memory:3529:7: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

The failures there I fixed locally by bumping the SDK versions in:

https://github.com/flutter/buildroot/blob/master/build/config/mac/mac_sdk.gni

up to 10.14, but I'm not actually sure that's the right thing to do.

@jmagman
Copy link
Member Author
jmagman commented Oct 11, 2021 •
edited
Loading

I think this logic needs to be updated to set use_xcode for your arm build. flutter/buildroot#422 Does that fix it?
https://github.com/flutter/buildroot/blob/fc82ca44f1ae85c5fbfa06bd313477539ca50729/build/toolchain/clang.gni#L50

    use_xcode = (enable_bitcode && !bitcode_marker) || (use_ios_simulator && target_cpu == "arm64")

I think mac_deployment_target needs to stay at 10.11 unless we migrate plugins and apps to support a minimum of 10.14 (released in 2018). That means that some hardware that could run 10.11 would no longer be supported by new Flutter apps.
macOS 10.11 hardware requirements: https://support.apple.com/kb/sp728?locale=en_US
macOS 10.14 hardware requirements: https://support.apple.com/kb/SP777?locale=en_US

This is the work I needed to do to change the minimum from iOS 8->9, I'd expect the macOS change to be similar:
#62902 (template)
#85174 (migration)
#86840 (framework template)
#84198 (plugins)
#89621 (integraton_test package)
flutter/engine#28743 (engine Info.plist)
Bonus doc: flutter/website#6057

However I don't think the version upgrade is needed in this case, just to use the Xcode version of clang.

@jmagman
Copy link
Member Author
jmagman commented Oct 11, 2021 •
edited
Loading

Trying this now. For posterity, I needed a \ before the $ in \$flutter/osx_sdk=...

https://ci.chromium.org/swarming/task/568a1f2b9d4a4710?server=chromium-swarm.appspot.com

It's fine to test, but to reiterate we can't use the 12c33 clang version in prod. I'll work on getting the macOS 11 SDK in the 12a7209 cipd package.

@zanderso
Copy link
Member

Need to pass -fno-aligned-allocation for macOS arm64 like we do for iOS arm: flutter/buildroot#517

8000

This was referenced Oct 13, 2021
Merged
Merged
@jmagman jmagman mentioned this issue Oct 19, 2021
Closed
@jmagman
Copy link
Member Author
jmagman commented Oct 19, 2021

We need to add macOS 11 (Big Sur) SDK to the existing 12a7209 cipd package.

I'll work on that now.

I've been trying to get the Xcode cipd package uploaded, but since it's the same Xcode version as an existing one (but with an additional macOS SDK), and the ref is automatically set to the Xcode version, and it causes duplicates. I filed #92051 to pick up https://chromium-review.googlesource.com/c/infra/infra/+/3219264

@jmagman
Copy link
Member Author
jmagman commented Oct 22, 2021 •
edited
Loading

Trying out the new Xcode version https://ci.chromium.org/swarming/task/56befe2bcfb8d510?server=chromium-swarm.appspot.com

@jmagman
Copy link
Member Author
jmagman commented Oct 26, 2021

This one worked:
https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/magder_google.com/203581ea3aba655c835c078b8d1b35cbaea22ec27c65ef72e9e1806297d1512b/+/build.proto?server=chromium-swarm.appspot.com

The failures there I fixed locally by bumping the SDK versions in:

https://github.com/flutter/buildroot/blob/master/build/config/mac/mac_sdk.gni

up to 10.14, but I'm not actually sure that's the right thing to do.

@zanderso Can you try again with your recipe changed to:

"sdk_version": "12a7209sdkbigsur1"

"xcode": "12a7209sdkbigsur1"

Open to suggestions for a better name for this package, which is 12a7209 + the first macOS 11 Big Sur SDK. The name needs to be alphanumeric only.

@zanderso
Copy link
Member

@jmagman this is on my radar. I'll hopefully be able to give it a shot today or tomorrow.

@a-siva a-siva mentioned this issue Nov 1, 2021
Closed
@zanderso
Copy link
Member
zanderso commented Nov 3, 2021

Sorry for the delay. It looks like even with the new cipd package, the build is still trying to use the older SDK (?)

https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/zra_google.com/a12f4b524d11e2bea291202ebb9e8d677f41ebc91745578b3aaa59513de128bb/+/build.proto?server=chromium-swarm.appspot.com

@jmagman
Copy link
Member Author
jmagman commented Nov 3, 2021 •
edited
Loading

Ugh I messed it up, I added macOS 10.15 (Catalina) instead of macOS 11 (Big Sur)
The old error was:

error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

The new error shows it's using MacOSX10.15 but it should be using MacOSX11.0

/opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */

However, I think this is showing that our version of clang is too old to handle even MacOSX10.15. I think we may need to update clang, which means this is dependent on bumping the tools minimum Xcode version to 12.2, and therefore all our developers would need to update their version of Xcode to at least 12.2 (the old bitcode issue).

@jmagman
Copy link
Member Author
jmagman commented Nov 3, 2021

Note to self, Zach's recipe change is at https://flutter-review.googlesource.com/c/recipes/+/19301/

This was referenced Nov 5, 2021
Closed
Merged
@jmagman
Copy link
Member Author
jmagman commented Nov 5, 2021

Well, you already proved 12.3 12c33 worked, so let's just bump the minimum version enforced to the tool to that, then we can use that version in Mac Host Engine at least and avoid bitcode and issues where the old 12.0 clang can't parse the macOS 11 SDK.
#93094

This was referenced Nov 5, 2021
Closed
Closed
@jmagman jmagman mentioned this issue Dec 15, 2021
Merged
8 tasks
@zanderso
Copy link
Member

This is ready to land here https://flutter-review.googlesource.com/c/recipes/+/25800. Since this is a bit risky, I'll wait until off-hours to click the button.
628C

@knopp knopp mentioned this issue Jan 31, 2022
Closed
@jmagman
Copy link
Member Author
jmagman commented Feb 9, 2022

@zanderso is there more to track here or can this be closed?

@zanderso
Copy link
Member
zanderso commented Feb 9, 2022

This is done.

@zanderso zanderso closed this as completed Feb 9, 2022
@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
engine flutter/engine repository. See also e: labels. P2 Important issues not at the top of the work list team Infra upgrades, team productivity, code health, technical debt. See also team: labels. team-infra Owned by Infrastructure team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jmagman @zanderso @godofredoc
0