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

Fix incorrect 'llvm_target' value used on watchOS target #123446

Merged
merged 1 commit into from
Apr 7, 2024

Conversation

crazytonyli
Copy link
Contributor

@crazytonyli crazytonyli commented Apr 4, 2024

Issue

xcodebuild -create-xcframework command doesn't recognize static libraries that are built on "arm64_32-apple-watchos" target.

Here are steps to reproduce the issue on a Mac:

  1. Install nightly toolchain nightly-2024-03-27. Needs this specific version, because newer nightly versions are broken on watchos target.
  2. Create an empty library: mkdir watchos-lib && cd watchos-lib && cargo init --lib.
  3. Add configuration lib.crate-type=["staticlib"] to Cargo.toml.
  4. Build the library: cargo +nightly-2024-03-27 build --release -Zbuild-std --target arm64_32-apple-watchos
  5. Run xcodebuild -create-xcframework to put the static library into a xcframework, which results in an error:
$ xcodebuild -create-xcframework -library target/arm64_32-apple-watchos/release/libwatchos_lib.a -output test.xcframework
error: unable to determine the platform for the given binary '.../watchos-lib/target/arm64_32-apple-watchos/release/libwatchos_lib.a'; check your deployment version settings

Fix

The root cause of this error is xcodebuild couldn't read LC_BUILD_VERSION from the static library to determine the library's target platform. And the reason it's missing is that an incorrect llvm_target value is used in arm64_32-apple-watchos target. The expected value is <arch>-apple-watchos<major>.<minor>.0, i.e. "arm64_32-apple-watchos8.0.0".

The .../apple/mod.rs file contains functions that construct such string. There is an existing function watchos_sim_llvm_target which returns llvm target value for watchOS simulator. But there is none for watchOS device. This PR adds that missing function to align watchOS with other Apple platform targets.

To verify the fix, you can simply build a toolchain on this PR branch and repeat the steps above using the built local toolchain to verify the xcodebuild -create-xcframework command can create a xcframework successfully.

Furthermore, you can verify LC_BUILD_VERSION contains correct info by using the simple shell script below to print LC_BUILD_VERSION of the static library that's built on watchos target:

bin=target/arm64_32-apple-watchos/release/libwatchos_lib.a
file=$(ar -t "$bin" | grep -E '\.o$' | head -n 1)
ar -x "$bin" "$file"
vtool -show-build-version "$file"

Here is an example output from my machine:

watchos_rust-495d6aaf3bccc08d.watchos_rust.35ba42bf9255ca9d-cgu.0.rcgu.o:
Load command 1
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform WATCHOS
    minos 8.0
      sdk n/a
   ntools 0

The expected value is "<arch>-apple-watchos<major>.<minor>.0", i.e.
"arm64_32-apple-watchos8.0.0".

compiler/rustc_target/src/spec/base/apple/mod.rs contains functions that
construct such string. There is an existing function
`watchos_sim_llvm_target` which returns llvm target value for watchOS
simulator. But there is none for watchOS device. This commit adds that
missing function to align watchOS with other Apple platform targets.
@rustbot
Copy link
Collaborator

rustbot commented Apr 4, 2024

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) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 4, 2024
@rustbot
Copy link
Collaborator

rustbot commented Apr 4, 2024

These commits modify compiler targets.
(See the Target Tier Policy.)

@estebank
Copy link
Contributor

estebank commented Apr 6, 2024

cc @rust-lang/compiler for changes to watch OS target

The changes look reasonable.

@bors r+

@bors
Copy link
Contributor

bors commented Apr 6, 2024

📌 Commit 1ffb410 has been approved by estebank

It is now in the queue for this repository.

@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 Apr 6, 2024
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Apr 6, 2024
…t, r=estebank

Fix incorrect 'llvm_target' value used on watchOS target

## Issue

`xcodebuild -create-xcframework` command doesn't recognize static libraries that are built on "arm64_32-apple-watchos" target.

Here are steps to reproduce the issue on a Mac:
1. Install nightly toolchain `nightly-2024-03-27`. Needs this specific version, because newer nightly versions are broken on watchos target.
1. Create an empty library: `mkdir watchos-lib && cd watchos-lib && cargo init --lib`.
1. Add configuration `lib.crate-type=["staticlib"]` to Cargo.toml.
1. Build the library: `cargo +nightly-2024-03-27 build --release -Zbuild-std --target arm64_32-apple-watchos`
1. Run `xcodebuild -create-xcframework` to put the static library into a xcframework, which results in an error:

```
$ xcodebuild -create-xcframework -library target/arm64_32-apple-watchos/release/libwatchos_lib.a -output test.xcframework
error: unable to determine the platform for the given binary '.../watchos-lib/target/arm64_32-apple-watchos/release/libwatchos_lib.a'; check your deployment version settings
```

## Fix

The root cause of this error is `xcodebuild` couldn't read `LC_BUILD_VERSION` from the static library to determine the library's target platform. And the reason it's missing is that an incorrect `llvm_target` value is used in `arm64_32-apple-watchos` target. The expected value is `<arch>-apple-watchos<major>.<minor>.0`, i.e. "arm64_32-apple-watchos8.0.0".

The [.../apple/mod.rs](https://github.com/rust-lang/rust/blob/43f4f2a3b1a3d3fb3dbbbe4fde33fb97c780ee98/compiler/rustc_target/src/spec/base/apple/mod.rs#L321) file contains functions that construct such string. There is an existing function `watchos_sim_llvm_target` which returns llvm target value for watchOS simulator. But there is none for watchOS device. This PR adds that missing function to align watchOS with other Apple platform targets.

To verify the fix, you can simply build a toolchain on this PR branch and repeat the steps above using the built local toolchain to verify the `xcodebuild -create-xcframework` command can create a xcframework successfully.

Furthermore, you can verify `LC_BUILD_VERSION` contains correct info by using the simple shell script below to print `LC_BUILD_VERSION` of the static library that's built on watchos target:

```shell
bin=target/arm64_32-apple-watchos/release/libwatchos_lib.a
file=$(ar -t "$bin" | grep -E '\.o$' | head -n 1)
ar -x "$bin" "$file"
vtool -show-build-version "$file"
```

Here is an example output from my machine:

```
watchos_rust-495d6aaf3bccc08d.watchos_rust.35ba42bf9255ca9d-cgu.0.rcgu.o:
Load command 1
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform WATCHOS
    minos 8.0
      sdk n/a
   ntools 0
```
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 6, 2024
…llaumeGomez

Rollup of 4 pull requests

Successful merges:

 - rust-lang#119224 (Drop panic hook after running tests)
 - rust-lang#123411 (Put checks that detect UB under their own flag below debug_assertions)
 - rust-lang#123446 (Fix incorrect 'llvm_target' value used on watchOS target)
 - rust-lang#123516 (Do not ICE on field access check on expr with `ty::Error`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 7, 2024
…iaskrgr

Rollup of 4 pull requests

Successful merges:

 - rust-lang#123410 (Relax framework linking test)
 - rust-lang#123446 (Fix incorrect 'llvm_target' value used on watchOS target)
 - rust-lang#123579 (add some more tests)
 - rust-lang#123581 (Add `f16` and `f128` to rustdoc's `PrimitiveType`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit dc387cf into rust-lang:master Apr 7, 2024
11 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Apr 7, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 7, 2024
Rollup merge of rust-lang#123446 - crazytonyli:fix-watchos-llvm-target, r=estebank

Fix incorrect 'llvm_target' value used on watchOS target

## Issue

`xcodebuild -create-xcframework` command doesn't recognize static libraries that are built on "arm64_32-apple-watchos" target.

Here are steps to reproduce the issue on a Mac:
1. Install nightly toolchain `nightly-2024-03-27`. Needs this specific version, because newer nightly versions are broken on watchos target.
1. Create an empty library: `mkdir watchos-lib && cd watchos-lib && cargo init --lib`.
1. Add configuration `lib.crate-type=["staticlib"]` to Cargo.toml.
1. Build the library: `cargo +nightly-2024-03-27 build --release -Zbuild-std --target arm64_32-apple-watchos`
1. Run `xcodebuild -create-xcframework` to put the static library into a xcframework, which results in an error:

```
$ xcodebuild -create-xcframework -library target/arm64_32-apple-watchos/release/libwatchos_lib.a -output test.xcframework
error: unable to determine the platform for the given binary '.../watchos-lib/target/arm64_32-apple-watchos/release/libwatchos_lib.a'; check your deployment version settings
```

## Fix

The root cause of this error is `xcodebuild` couldn't read `LC_BUILD_VERSION` from the static library to determine the library's target platform. And the reason it's missing is that an incorrect `llvm_target` value is used in `arm64_32-apple-watchos` target. The expected value is `<arch>-apple-watchos<major>.<minor>.0`, i.e. "arm64_32-apple-watchos8.0.0".

The [.../apple/mod.rs](https://github.com/rust-lang/rust/blob/43f4f2a3b1a3d3fb3dbbbe4fde33fb97c780ee98/compiler/rustc_target/src/spec/base/apple/mod.rs#L321) file contains functions that construct such string. There is an existing function `watchos_sim_llvm_target` which returns llvm target value for watchOS simulator. But there is none for watchOS device. This PR adds that missing function to align watchOS with other Apple platform targets.

To verify the fix, you can simply build a toolchain on this PR branch and repeat the steps above using the built local toolchain to verify the `xcodebuild -create-xcframework` command can create a xcframework successfully.

Furthermore, you can verify `LC_BUILD_VERSION` contains correct info by using the simple shell script below to print `LC_BUILD_VERSION` of the static library that's built on watchos target:

```shell
bin=target/arm64_32-apple-watchos/release/libwatchos_lib.a
file=$(ar -t "$bin" | grep -E '\.o$' | head -n 1)
ar -x "$bin" "$file"
vtool -show-build-version "$file"
```

Here is an example output from my machine:

```
watchos_rust-495d6aaf3bccc08d.watchos_rust.35ba42bf9255ca9d-cgu.0.rcgu.o:
Load command 1
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform WATCHOS
    minos 8.0
      sdk n/a
   ntools 0
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

4 participants