Skip to content

[MacCatalyst]: Can't determine the platform when creating an xcframework from rust libraries #107630

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
Milerius opened this issue Feb 3, 2023 · 3 comments · Fixed by #129341
Closed
Labels
C-bug Category: This is a bug. O-ios Operating system: iOS

Comments

@Milerius
Copy link

Milerius commented Feb 3, 2023

Hello I'm using aarch64-apple-ios-macabi and x86_64-apple-ios-macabi as follow in my project:

CARGO_TARGET_DIR=$BUILD_FOLDER cargo +nightly build -Z build-std --target aarch64-apple-ios-macabi --release
CARGO_TARGET_DIR=$BUILD_FOLDER cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi --release
lipo $BUILD_FOLDER/aarch64-apple-ios-macabi/release/$TARGET_NAME $BUILD_FOLDER/x86_64-apple-ios-macabi/release/$TARGET_NAME -create -output $BUILD_FOLDER/catalyst/$TARGET_NAME

xcodebuild -create-xcframework -library $BUILD_FOLDER/$TARGET_NAME -library $BUILD_FOLDER/darwin_universal/$TARGET_NAME -library $BUILD_FOLDER/aarch64-apple-ios/release/$TARGET_NAME -library $BUILD_FOLDER/catalyst/$TARGET_NAME -output $TARGET_XCFRAMEWORK_NAME

Was working fine until XCode 14.2 release which now produce:

error: unable to determine the platform for the given binary 'project/build/local/catalyst/libproject_rs.a'; check your deployment version settings

This is the json target spec for MacCatalyst (aarch64):

{
  "abi": "macabi",
  "abi-return-struct-as-int": true,
  "arch": "aarch64",
  "archive-format": "darwin",
  "bitcode-llvm-cmdline": "-triple\u0000arm64-apple-ios-macabi\u0000-emit-obj\u0000-disable-llvm-passes\u0000-Os\u0000",
  "cpu": "apple-a12",
  "data-layout": "e-m:o-i64:64-i128:128-n32:64-S128",
  "debuginfo-kind": "dwarf-dsym",
  "default-dwarf-version": 2,
  "dll-suffix": ".dylib",
  "dynamic-linking": true,
  "eh-frame-header": false,
  "emit-debug-gdb-scripts": false,
  "features": "+neon,+fp-armv8,+apple-a12",
  "forces-embed-bitcode": true,
  "frame-pointer": "non-leaf",
  "function-sections": false,
  "has-rpath": true,
  "is-builtin": true,
  "is-like-osx": true,
  "link-env": [
    "ZERO_AR_DATE=1"
  ],
  "link-env-remove": [
    "IPHONEOS_DEPLOYMENT_TARGET"
  ],
  "linker-is-gnu": false,
  "lld-flavor": "darwin",
  "llvm-target": "arm64-apple-ios-macabi",
  "max-atomic-width": 128,
  "os": "ios",
  "pre-link-args": {
    "gcc": [
      "-target",
      "arm64-apple-ios-macabi"
    ],
    "ld": [
      "-arch",
      "arm64",
      "-platform_version",
      "mac-catalyst",
      "7.0",
      "7.0"
    ],
    "ld64.lld": [
      "-arch",
      "arm64",
      "-platform_version",
      "mac-catalyst",
      "7.0",
      "7.0"
    ]
  },
  "split-debuginfo": "packed",
  "supported-split-debuginfo": [
    "packed",
    "unpacked",
    "off"
  ],
  "target-family": [
    "unix"
  ],
  "target-pointer-width": "64",
  "vendor": "apple"
}

Every other targets outside of catalyst seems to work

Meta

rustc --version --verbose:

rustc 1.69.0-nightly (f3126500f 2023-02-02)
binary: rustc
commit-hash: f3126500f25114ba4e0ac3e76694dd45a22de56d
commit-date: 2023-02-02
host: aarch64-apple-darwin
release: 1.69.0-nightly
LLVM version: 15.0.7

Maybe XCode have new requirements that the targets doesn't respect correctly? and therefore xcodebuild can't create an xcframework from any catalyst library?

Simple repro:

rustup update
  rustup toolchain install nightly
  rustup default nightly
  rustup toolchain install nightly-x86_64-apple-darwin
  rustup toolchain install nightly-aarch64-apple-darwin
  rustup component add rust-src --toolchain nightly-aarch64-apple-darwin
  rustup component add rust-src --toolchain nightly-x86_64-apple-darwin
rustup target add aarch64-apple-darwin x86_64-apple-darwin
rustup target add x86_64-apple-ios aarch64-apple-ios-sim aarch64-apple-ios 
cargo build --target aarch64-apple-ios --release
cargo build --target aarch64-apple-ios-sim --release
 cargo build --target x86_64-apple-ios --release
 cargo build --target aarch64-apple-darwin --release
 cargo build --target x86_64-apple-darwin --release
 cargo +nightly build -Z build-std --target aarch64-apple-ios-macabi --release
 cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi --release

lipo build_folder/x86_64-apple-ios/release/lib_name.a build_folder/aarch64-apple-ios-sim/release/libname.a -create -output build_folder/libname.a

 mkdir -p build_folder/darwin_universal
  lipo build_folder/x86_64-apple-darwin/release/libname.a build_folder/aarch64-apple-darwin/release/libname.a -create -output build_folder/darwin_universal/libname.a
  mkdir -p build_folder//catalyst
  lipo build_folder/aarch64-apple-ios-macabi/release/libname.a build_folder/x86_64-apple-ios-macabi/release/libname.a -create -output build_folder/catalyst/libname.a

## Will fail on catalyst with `error: unable to determine the platform for the given binary 'project/build/local/catalyst/libname.a'; check your deployment version settings`  
    xcodebuild -create-xcframework -library $BUILD_FOLDER/$TARGET_NAME -library $BUILD_FOLDER/darwin_universal/$TARGET_NAME -library $BUILD_FOLDER/aarch64-apple-ios/release/$TARGET_NAME -library $BUILD_FOLDER/catalyst/$TARGET_NAME -output $TARGET_XCFRAMEWORK_NAME

@Milerius Milerius added the C-bug Category: This is a bug. label Feb 3, 2023
@workingjubilee workingjubilee added the O-ios Operating system: iOS label Mar 2, 2023
@keith
Copy link
Contributor

keith commented Jul 27, 2023

I can't reproduce this, what crate-type was your case? I assume staticlib but I didn't have any luck with that and Xcode 14.2 (it could be fixed in a newer Xcode version too I guess)

@PrismaPhonic
Copy link

I'm getting similar errors now when building for the watchos target. Nearly identical xcodebuild command (except that I'm not using lipo at all, and only testing with a single target). Other apple targets work fine for me, and even the watchos-sim works for me, but failing on unable to determine platform. My issue may be unrelated but does seem oddly similar

@madsmtm
Copy link
Contributor

madsmtm commented Aug 21, 2024

I believe that the issue may have been that we previously only passed arm64-apple-ios-macabi as the LLVM target, where we should have been passing arm64-apple-ios13.1-macabi (with 13.1 being the deployment target). That part was fixed in #111384, the aarch64-apple-watchos target having the same problem should be fixed by #129341.

@bors bors closed this as completed in 9afe713 Sep 7, 2024
RalfJung pushed a commit to RalfJung/miri that referenced this issue Sep 10, 2024
…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.
lnicola pushed a commit to lnicola/rust-analyzer that referenced this issue Sep 25, 2024
…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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug. O-ios Operating system: iOS
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants