-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
WatchOS Target: Unrecognized deployment version by xcodebuild #123582
Comments
Whoops, accidentally closed - sorry about that |
have a few questions
|
I can get it to work in an Apple Watch app if I manually link the static library file generated from my rust project, however it will only work for debug runs pushed to the watch wirelessly for testing. Any attempt to make an archive build results in similar errors inside xcode. The build command actually comes from
If I run that exact same EDIT: Forgot to answer your second question. It is a hybrid project, however only the WatchOS project needs the generated library from the xcodebuild command. I currently have it linked manually and it "works" in the way I've described above. I can't currently generate the library at all when using the non sim watchos targets |
I reproduced your problem and tried some fixes, I don't know if this will solve your problem, but there are no errors with your simplified xcodebuild command. cargo build -Zbuild-std=std,panic_abort --target aarch64-apple-watchos --release
cargo build -Zbuild-std=std,panic_abort --target arm64_32-apple-watchos --release
cargo build -Zbuild-std=std,panic_abort --target armv7k-apple-watchos --release
lipo -create target/aarch64-apple-watchos/release/libtest_watchos.a\
target/arm64_32-apple-watchos/release/libtest_watchos.a\
target/armv7k-apple-watchos/release/libtest_watchos.a\
-o libtest_watchos_lipo.a
lipo -info libtest_watchos_lipo.a
# output: Architectures in the fat file: libtest_watchos_lipo.a are: arm64_32 armv7k arm64
xcodebuild -create-xcframework -library libtest_watchos_lipo.a -output test.xcframework
# xcframework successfully written out to: test.xcframework Main reference documents |
Ahh interesting - so it seems that lipo does need to be used to combine all possible watch architectures then? I'll give that a try and report back, thank you |
I still get the same error:
|
Xcode version 15.3 for reference, in case this is a requirement of an xcode version newer than the one you're testing with |
…enkov Apple: Refactor deployment target version parsing Refactor deployment target parsing to make it easier to do rust-lang/rust#129342 (I wanted to make sure of all the places that `std::env::var` is called). Specifically, my goal was to minimize the amount of target-specific configuration, so to that end I renamed the `opts` function that generates the `TargetOptions` to `base`, and made it return the LLVM target and `target_arch` too. In the future, I would like to move even more out of the target files and into `spec::apple`, as it makes it easier for me to maintain. For example, this fixed a bug in `aarch64-apple-watchos`, which wasn't passing the deployment target as part of the LLVM triple. This (probably) fixes rust-lang/rust#123582 and fixes rust-lang/rust#107630. We also now parse the patch version of deployment targets, allowing the user to specify e.g. `MACOSX_DEPLOYMENT_TARGET=10.12.6`. Finally, this fixes the LLVM target name for visionOS, it should be `*-apple-xros` and not `*-apple-visionos`. Since I have changed all the Apple targets here, I smoke-tested my changes by running the following: ```console # Build each target ./x build library --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,arm64e-apple-ios,armv7k-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" # Test that we can still at least link basic projects cargo new foobar && cd foobar && cargo +stage1 build --target=aarch64-apple-darwin --target=aarch64-apple-ios --target=aarch64-apple-ios-macabi --target=aarch64-apple-ios-sim --target=aarch64-apple-tvos --target=aarch64-apple-tvos-sim --target=aarch64-apple-visionos --target=aarch64-apple-visionos-sim --target=aarch64-apple-watchos --target=aarch64-apple-watchos-sim --target=arm64_32-apple-watchos --target=armv7s-apple-ios --target=i386-apple-ios --target=x86_64-apple-darwin --target=x86_64-apple-ios --target=x86_64-apple-ios-macabi --target=x86_64-apple-tvos --target=x86_64-apple-watchos-sim --target=x86_64h-apple-darwin ``` I couldn't build for the `arm64e-apple-darwin` target, the `armv7k-apple-watchos` and `arm64e-apple-ios` targets failed to link, and I know that the `i686-apple-darwin` target requires a bit of setup, but all of this is as it was before this PR. r? thomcc CC `@BlackHoleFox` I would recommend using `rollup=never` when merging this, in case we need to bisect this later.
…enkov Apple: Refactor deployment target version parsing Refactor deployment target parsing to make it easier to do rust-lang/rust#129342 (I wanted to make sure of all the places that `std::env::var` is called). Specifically, my goal was to minimize the amount of target-specific configuration, so to that end I renamed the `opts` function that generates the `TargetOptions` to `base`, and made it return the LLVM target and `target_arch` too. In the future, I would like to move even more out of the target files and into `spec::apple`, as it makes it easier for me to maintain. For example, this fixed a bug in `aarch64-apple-watchos`, which wasn't passing the deployment target as part of the LLVM triple. This (probably) fixes rust-lang/rust#123582 and fixes rust-lang/rust#107630. We also now parse the patch version of deployment targets, allowing the user to specify e.g. `MACOSX_DEPLOYMENT_TARGET=10.12.6`. Finally, this fixes the LLVM target name for visionOS, it should be `*-apple-xros` and not `*-apple-visionos`. Since I have changed all the Apple targets here, I smoke-tested my changes by running the following: ```console # Build each target ./x build library --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,arm64e-apple-ios,armv7k-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" # Test that we can still at least link basic projects cargo new foobar && cd foobar && cargo +stage1 build --target=aarch64-apple-darwin --target=aarch64-apple-ios --target=aarch64-apple-ios-macabi --target=aarch64-apple-ios-sim --target=aarch64-apple-tvos --target=aarch64-apple-tvos-sim --target=aarch64-apple-visionos --target=aarch64-apple-visionos-sim --target=aarch64-apple-watchos --target=aarch64-apple-watchos-sim --target=arm64_32-apple-watchos --target=armv7s-apple-ios --target=i386-apple-ios --target=x86_64-apple-darwin --target=x86_64-apple-ios --target=x86_64-apple-ios-macabi --target=x86_64-apple-tvos --target=x86_64-apple-watchos-sim --target=x86_64h-apple-darwin ``` I couldn't build for the `arm64e-apple-darwin` target, the `armv7k-apple-watchos` and `arm64e-apple-ios` targets failed to link, and I know that the `i686-apple-darwin` target requires a bit of setup, but all of this is as it was before this PR. r? thomcc CC `@BlackHoleFox` I would recommend using `rollup=never` when merging this, in case we need to bisect this later.
When compiling for aarch64-apple-watchos target, building is successful, but when trying to pipe the generated binaries into xcodebuild I get:
This issue does not occur oddly with aarch64-apple-watchos-sim target, which works perfectly. It does however happen with every non simulator target for apple watch at the moment
The text was updated successfully, but these errors were encountered: