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

Add Catalyst (iOS apps running on macOS) target #63467

Merged
merged 1 commit into from
Aug 15, 2019
Merged

Add Catalyst (iOS apps running on macOS) target #63467

merged 1 commit into from
Aug 15, 2019

Conversation

terhechte
Copy link
Contributor

@terhechte terhechte commented Aug 11, 2019

This is a first attempt of adding support for the new Apple Catalyst target (i.e. running iOS apps on macOS). Currently, rustc supports the iOS and iOS simulator targets for iOS:

  • iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
  • Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI

Apple Catalyst will add an additional target:

  • Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.

Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.

I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made.

Open Questions:

Clang Version

It seems to me that macabi has not been merged into clang yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)

Hardcoded iOS version

swift-llvm actually used x86_64-apple-ios13.0-macabi as the target triple which hard-codes the current iOS version. A post on stackoverflow points out that MIN_IOS_VERSION and MIN_OSX_VERSION should be used when compiling C code for clang (-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi). However, I wasn't entirely sure how to do that in this PR. Pointers welcome.

Data Layout

I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK.

Current State

  1. I got it to compile
  2. I could successfully compile a macabi libcore via cargo build --target x86_64-apple-ios-macabi

I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via rustup to make sure that a binary compiled against the toolchain also works with Catalyst. I read this article, but I'm still lost and would love pointers what to do next here.

Additional Information

This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI

Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.

Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.

This commits adds the files for this new target triple.
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 11, 2019
@estebank
Copy link
Contributor

cc @alexcrichton everything seems correct, but I am unsure about:

It seems to me that macabi has not been merged into clang yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)

@alexcrichton
Copy link
Member

In general we're extremely liberal with adding new targets to the compiler, so there's not much oversight nor much verification for correctness as targets are added. In that sense if a target wants to be added here before clang, that's ok. We don't really have anyone to say whether that's a good idea or not, it depends on who's adding the target basically to make that judgement call.

In terms of things like target naming, data layout, etc, afaik we don't really have answers and/or someone to answer questions. It's largely up to you adding the target to test it out and make sure it works

@terhechte
Copy link
Contributor Author

@alexcrichton Thanks for the info! I'll try to get this into a custom toolchain then so that I can see if it works as expected.

Just to make sure I'm understanding this correctly. The rust build will not fail just because this new Catalyst target is not supported by the default clang compiler (yet)?

Thanks!

@alexcrichton
Copy link
Member

Correct yeah, we don't build all targets by default, only a whitelist of targets. That means that if there's a bug in this target or something doesn't work as expected it won't block other builds

@estebank
Copy link
Contributor

Given @alexcrichton's comment,

@bors r+

@bors
Copy link
Contributor

bors commented Aug 14, 2019

📌 Commit af1e668 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 14, 2019
@Centril Centril added relnotes Marks issues that should be documented in the release notes of the next release. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 15, 2019
@Centril Centril added this to the 1.39 milestone Aug 15, 2019
Centril added a commit to Centril/rust that referenced this pull request Aug 15, 2019
…bi-target-triple, r=estebank

Add Catalyst (iOS apps running on macOS) target

This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI

Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.

Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.

I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made.

# Open Questions:

## Clang Version
It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)

## Hardcoded iOS version

`swift-llvm` actually used [x86_64-apple-ios13.0-macabi](apple/swift-llvm@3f1fd4f) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome.

## Data Layout
I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK.

# Current State
1. I got it to compile
2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi`

I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here.

# Additional Information
- [Commit adding Catalyst support to the Swift Clang Fork](CocoaPods/CocoaPods#8877)
- [Compiling C to Catalyst Discussion](CocoaPods/CocoaPods#8877)
- [CocoaPods Discussion on Adding Catalyst support](CocoaPods/CocoaPods#8877)
Centril added a commit to Centril/rust that referenced this pull request Aug 15, 2019
…bi-target-triple, r=estebank

Add Catalyst (iOS apps running on macOS) target

This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI

Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.

Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.

I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made.

# Open Questions:

## Clang Version
It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)

## Hardcoded iOS version

`swift-llvm` actually used [x86_64-apple-ios13.0-macabi](apple/swift-llvm@3f1fd4f) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome.

## Data Layout
I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK.

# Current State
1. I got it to compile
2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi`

I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here.

# Additional Information
- [Commit adding Catalyst support to the Swift Clang Fork](CocoaPods/CocoaPods#8877)
- [Compiling C to Catalyst Discussion](CocoaPods/CocoaPods#8877)
- [CocoaPods Discussion on Adding Catalyst support](CocoaPods/CocoaPods#8877)
bors added a commit that referenced this pull request Aug 15, 2019
Rollup of 9 pull requests

Successful merges:

 - #63155 (Add UWP MSVC targets)
 - #63165 (Add builtin targets for mips64(el)-unknown-linux-muslabi64)
 - #63306 (Adapt AddRetag for shallow retagging)
 - #63467 (Add Catalyst (iOS apps running on macOS) target)
 - #63546 (Remove uses of `mem::uninitialized()` from cloudabi)
 - #63572 (remove unused Level::PhaseFatal)
 - #63577 (Test HRTB issue accepted by compiler)
 - #63582 (Fix ICE #63226)
 - #63586 (cleanup: Remove `Spanned` where possible)

Failed merges:

r? @ghost
@terhechte
Copy link
Contributor Author

Thanks! I'll continue and try to build a toolchain that can be used to compile a library that has the correct macabi and then report back.

@bors bors merged commit af1e668 into rust-lang:master Aug 15, 2019
@terhechte terhechte deleted the support-ios-catalyst-macabi-target-triple branch September 26, 2019 12:44
@simlay simlay mentioned this pull request Jan 13, 2020
bors added a commit that referenced this pull request Feb 27, 2020
Added tvOS as targets

This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs).

I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV, Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell, all three targets (iOS, tvOS, and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts?

As far as the `data_layout` and other parameters to `Target`, I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters.

I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`).

I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this?

Similar to the ending of #63467, I'm not sure what to do next.
Centril added a commit to Centril/rust that referenced this pull request Mar 11, 2020
Added tvOS as targets

This is a first attempt of adding support tvOS as described in rust-lang#48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs).

I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV, Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell, all three targets (iOS, tvOS, and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts?

As far as the `data_layout` and other parameters to `Target`, I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters.

I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`).

I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this?

Similar to the ending of rust-lang#63467, I'm not sure what to do next.
Centril added a commit to Centril/rust that referenced this pull request Mar 11, 2020
Added tvOS as targets

This is a first attempt of adding support tvOS as described in rust-lang#48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs).

I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV, Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell, all three targets (iOS, tvOS, and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts?

As far as the `data_layout` and other parameters to `Target`, I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters.

I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`).

I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this?

Similar to the ending of rust-lang#63467, I'm not sure what to do next.
bors added a commit that referenced this pull request Mar 12, 2020
Added tvOS as targets

This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs).

I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV, Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell, all three targets (iOS, tvOS, and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts?

As far as the `data_layout` and other parameters to `Target`, I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters.

I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`).

I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this?

Similar to the ending of #63467, I'm not sure what to do next.
ehuss added a commit to ehuss/rust-forge that referenced this pull request May 15, 2020
- aarch64-unknown-none: rust-lang/rust#68334
- aarch64-unknown-none-softfloat: rust-lang/rust#64589
- armv7-unknown-linux-gnueabi: rust-lang/rust#63107
- armv7-unknown-linux-musleabi: rust-lang/rust#63107
- aarch64-apple-tvos: rust-lang/rust#68191
- armv7a-none-eabihf: rust-lang/rust#68253
- i686-unknown-uefi: rust-lang/rust#64334
- thumbv7neon-unknown-linux-musleabihf: rust-lang/rust#66103
- x86_64-apple-ios-macabi: rust-lang/rust#63467
- x86_64-apple-tvos: rust-lang/rust#68191
- x86_64-linux-kernel: rust-lang/rust#64051
- x86_64-unknown-hermit-kernel: rust-lang/rust#66713
- x86_64-unknown-illumos: rust-lang/rust#71145

Moved to tier 2:
- aarch64-unknown-none: rust-lang/rust#68334
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 17, 2020
…bi-arm64-target-triple, r=nikomatsakis

Add support for Arm64 Catalyst on ARM Macs

This is an iteration on rust-lang#63467 which was merged a while ago. In the aforementioned PR, I added support for the `X86_64-apple-ios-macabi` target triple, which is Catalyst, iOS apps running on macOS.

Very soon, Apple will launch ARM64 based Macs which will introduce `aarch64_apple_darwin.rs`, macOS apps using the Darwin ABI running on ARM. This PR adds support for Catalyst apps on ARM Macs: iOS apps compiled for the darwin ABI.

I don't have access to a Apple Developer Transition Kit (DTK), so I can't really test if the generated binaries work correctly. I'm vaguely hopeful that somebody with access to a DTK could give this a spin.
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 27, 2020
…-arm64-target-triple, r=nikomatsakis

Add support for Arm64 Catalyst on ARM Macs

This is an iteration on rust-lang#63467 which was merged a while ago. In the aforementioned PR, I added support for the `X86_64-apple-ios-macabi` target triple, which is Catalyst, iOS apps running on macOS.

Very soon, Apple will launch ARM64 based Macs which will introduce `aarch64_apple_darwin.rs`, macOS apps using the Darwin ABI running on ARM. This PR adds support for Catalyst apps on ARM Macs: iOS apps compiled for the darwin ABI.

I don't have access to a Apple Developer Transition Kit (DTK), so I can't really test if the generated binaries work correctly. I'm vaguely hopeful that somebody with access to a DTK could give this a spin.
spikespaz pushed a commit to spikespaz/dotwalk-rs that referenced this pull request Aug 29, 2024
Added tvOS as targets

This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs).

I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV, Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell, all three targets (iOS, tvOS, and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts?

As far as the `data_layout` and other parameters to `Target`, I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters.

I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`).

I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this?

Similar to the ending of rust-lang/rust#63467, I'm not sure what to do next.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants