You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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 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?
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.
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
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).
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 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.
Activity
zanderso commentedon Jun 11, 2021
/cc @gw280
godofredoc commentedon Aug 5, 2021
@jmagman @gw280 Is this blocked on something from infra?
jmagman commentedon 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 commentedon Aug 23, 2021
flutter_testerRosetta issue: #88106zanderso commentedon Oct 10, 2021
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.
[-]Build ARM during Mac Host Engine build[/-][+]Build arm64 during Mac Host Engine build[/+]jmagman commentedon Oct 11, 2021
@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 commentedon Oct 11, 2021
Here is a re-run https://ci.chromium.org/swarming/task/5689a49b6955b710?server=chromium-swarm.appspot.com
godofredoc commentedon Oct 11, 2021
Devicelab tests are currently using:
12c33Can you please add the following to your led command?
led edit -pa xcode=12c33 | led edit -pa $flutter/osx_sdk='{"sdk_version": "12c33" }'jmagman commentedon Oct 11, 2021
The builders can't use
12c33due 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.
5 remaining items
zanderso commentedon Oct 12, 2021
Need to pass
-fno-aligned-allocationfor macOS arm64 like we do for iOS arm: flutter-team-archive/buildroot#517jmagman commentedon Oct 19, 2021
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 commentedon Oct 22, 2021
Trying out the new Xcode version https://ci.chromium.org/swarming/task/56befe2bcfb8d510?server=chromium-swarm.appspot.com
jmagman commentedon 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
@zanderso Can you try again with your recipe changed to:
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 commentedon Oct 27, 2021
@jmagman this is on my radar. I'll hopefully be able to give it a shot today or tomorrow.
zanderso commentedon 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 commentedon Nov 3, 2021
Ugh I messed it up, I added macOS 10.15 (Catalina) instead of macOS 11 (Big Sur)
The old error was:
The new error shows it's using
MacOSX10.15but it should be usingMacOSX11.0However, 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 commentedon Nov 3, 2021
Note to self, Zach's recipe change is at https://flutter-review.googlesource.com/c/recipes/+/19301/
jmagman commentedon Nov 5, 2021
Well, you already proved 12.3
12c33worked, so let's just bump the minimum version enforced to the tool to that, then we can use that version inMac Host Engineat least and avoid bitcode and issues where the old 12.0 clang can't parse the macOS 11 SDK.#93094
zanderso commentedon Jan 28, 2022
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.
jmagman commentedon Feb 9, 2022
@zanderso is there more to track here or can this be closed?
zanderso commentedon Feb 9, 2022
This is done.
github-actions commentedon Feb 24, 2022
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 -vand a minimal reproduction of the issue.