Skip to content
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.

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

Upgrade our macOS build machines to the latest image #109454

Merged
merged 4 commits into from
Nov 5, 2024

Conversation

jkoritzinsky
Copy link
Member

@jkoritzinsky jkoritzinsky commented Nov 1, 2024

The macOS-12 image has been deprecated and will be removed in early December.

Let's move our macOS builds to use the macos-latest image.

This is the public equivalent of the 'macos-latest-internal' image we use for official builds already.

We need to backport this to enable public builds in our servicing PRs.

@jkoritzinsky
Copy link
Member Author

/backport to release/9.0-staging

@jkoritzinsky
Copy link
Member Author

/backport to release/8.0-staging

Copy link
Contributor

github-actions bot commented Nov 1, 2024

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11633383083

Copy link
Contributor

github-actions bot commented Nov 1, 2024

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/11633385070

@jkoritzinsky
Copy link
Member Author

Apparently AzDO doesn't support all of the images specified in https://github.com/actions/runner-images/blob/main/README.md. I guess I'll move us to macOS-13 (the last tag that corresponds to an x64 image) and we'll need to go through this song-and-dance again when that pool is deprecated.

@jkoritzinsky
Copy link
Member Author

/backport to release/9.0-staging

@jkoritzinsky
Copy link
Member Author

/backport to release/8.0-staging

Copy link
Contributor

github-actions bot commented Nov 1, 2024

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11633597484

Copy link
Contributor

github-actions bot commented Nov 1, 2024

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/11633599152

@jkoritzinsky
Copy link
Member Author

Looks like there's a linker issue with the Apple Cryptography code (I assume due to using a newer Xcode toolset).

@vcsjones @bartonjs can you take a look?

@vcsjones
Copy link
Member

vcsjones commented Nov 1, 2024

@akoeplinger this looks related to enabling Swift linking on iOS that was done in #104383.

/tmp/helix/working/BA9A0A0E/p/build/apple/AppleBuild.targets(301,5): error MSB4018: ld: warning: Could not find or use auto-linked library 'swiftXPC' [/private/tmp/helix/working/BA9A0A0E/w/A6B50900/e/publish/ProxyProjectForAOTOnHelix.proj]
/tmp/helix/working/BA9A0A0E/p/build/apple/AppleBuild.targets(301,5): error MSB4018: ld: warning: Could not find or use auto-linked library 'swiftObservation' [/private/tmp/helix/working/BA9A0A0E/w/A6B50900/e/publish/ProxyProjectForAOTOnHelix.proj]
/tmp/helix/working/BA9A0A0E/p/build/apple/AppleBuild.targets(301,5): error MSB4018: Undefined symbols for architecture arm64: [/private/tmp/helix/working/BA9A0A0E/w/A6B50900/e/publish/ProxyProjectForAOTOnHelix.proj]
/tmp/helix/working/BA9A0A0E/p/build/apple/AppleBuild.targets(301,5): error MSB4018:   "__swift_FORCE_LOAD_$_swiftXPC", referenced from: [/private/tmp/helix/working/BA9A0A0E/w/A6B50900/e/publish/ProxyProjectForAOTOnHelix.proj]
/tmp/helix/working/BA9A0A0E/p/build/apple/AppleBuild.targets(301,5): error MSB4018:       __swift_FORCE_LOAD_$_swiftXPC_$_pal_swiftbindings in libSystem.Security.Cryptography.Native.Apple.a(pal_swiftbindings.o) [/private/tmp/helix/working/BA9A0A0E/w/A6B50900/e/publish/ProxyProjectForAOTOnHelix.proj]

Any chance something jumps out at you as the cause of the issue?

@akoeplinger
Copy link
Member

@vcsjones looks like this is because we're now compiling using Xcode 15.4 on the AzDO build machine but the Helix machine is still using Xcode 14.3 and the static .a contains references to some swift libraries that the earlier Xcode doesn't provide. In general it seems Swift doesn't provide module backwards compatibility to earlier Xcode versions: https://developer.apple.com/forums/thread/749540

Some options:

  1. Switch back to Xcode 14 on the build machine. This is only possible on macos-13 since macos-14 will remove all but latest Xcodes soon: [macOS] Support policy changes; Xcode 14 and 16 will be removed from macOS 14 on November 4 actions/runner-images#10703
  2. Upgrade Helix machines to Xcode 15.4. This would also mean using a different Helix queue since macOS 13 we're currently using doesn't support Xcode 15.4, only up to 15.2 (or we try whether that combination works)
  3. Find some way to remove the swiftXPC reference from the binary since afaik we don't use it

@akoeplinger
Copy link
Member

akoeplinger commented Nov 4, 2024

I just saw that the 8.0/9.0 backport PRs using macos-13 are using Xcode 15.2 and apparently don't run into that issue so that's probably the quickest option.

It doesn't solve the official build problem in main (where we're using an image with Xcode 15.4 on it) since it effectively means we don't support earlier Xcodes anymore. /cc @vitek-karas
This might not be a huge issue since afaik Apple is already pretty strict on forcing users to latest Xcode but might be best to check with the xamarin-macios team.

@steveisok
Copy link
Member

It doesn't solve the official build problem in main (where we're using an image with Xcode 15.4 on it) since it effectively means we don't support earlier Xcodes anymore. /cc @vitek-karas This might not be a huge issue since afaik Apple is already pretty strict on forcing users to latest Xcode but might be best to check with the xamarin-macios team.

/cc @rolfbjarne @dalexsoto

@steveisok
Copy link
Member

I would prefer if we can get away w/ xcode latest.

@rolfbjarne
Copy link
Member

It doesn't solve the official build problem in main (where we're using an image with Xcode 15.4 on it) since it effectively means we don't support earlier Xcodes anymore. /cc @vitek-karas This might not be a huge issue since afaik Apple is already pretty strict on forcing users to latest Xcode but might be best to check with the xamarin-macios team.

/cc @rolfbjarne @dalexsoto

Currently it's possible to submit apps with Xcode 15 (presumably 15.0): "All iOS and iPadOS apps uploaded to App Store Connect must be built with a minimum of Xcode 15 and the iOS 17 SDK" (https://developer.apple.com/ios/submit/).

Xcode 15.[0-2]'s minimum macOS version is macOS 13.5 (https://xcodereleases.com/?scope=release).

Bumping to Xcode 15.3+ also means bumping the min macOS version to macOS 14.0 (https://xcodereleases.com/?scope=release).

This is a severe problem for people whose Macs can't update to macOS 14.0, which means that backporting this change to .NET 8 can mean a service update may force people to buy new Macs...

I think it's fine to bump the Xcode requirement to Xcode 15.2 though, everybody who's publishing apps to the App Store today should be able to upgrade to Xcode 15.2.

@jkoritzinsky
Copy link
Member Author

I'll change this PR back to using macOS 13 for now.

@vitek-karas
Copy link
Member

/fyi @matouskozak

@akoeplinger
Copy link
Member

akoeplinger commented Nov 5, 2024

If we keep using Xcode 15.2 then we could probably also switch to the macos-14 image since minor versions should still be there even after actions/runner-images#10703 (we'd need to add a step to set 15.2 as the selected Xcode version)

That said, I worry a bit for the official builds going forward since macos-latest-internal could be updated to macOS 15 / Xcode 16 at any time ...

@jkoritzinsky
Copy link
Member Author

We'll likely have to follow this up in a few months with a move to the macOS14 image when the macOS15 one is out. But for now I'll merge this in.

@jkoritzinsky
Copy link
Member Author

/ba-g tools timeout known

@jkoritzinsky jkoritzinsky merged commit ecd5ee7 into dotnet:main Nov 5, 2024
150 of 152 checks passed
@jkoritzinsky jkoritzinsky deleted the macos-build-machine-upgrade branch November 5, 2024 15:59
@akoeplinger
Copy link
Member

Another option would be to revive #108318 and get rid of the Swift code in the PAL.

@bartonjs
Copy link
Member

bartonjs commented Nov 5, 2024

Another option would be to revive #108318 and get rid of the Swift code in the PAL.

No.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

8 participants