Revert #110 to fix iOS cross-compilation after #158. Fixes #173 #176
Conversation
…Fixes rust-lang#173 In rust-lang#158, better support for using CMake's cross-compilation facilities was added. This made the workaround added in rust-lang#110 for iOS not only unnecessary, but actively harmful, in that it runs afoul of SDK validation checks in the CMake iOS codepath.
luser
changed the title
|
I pushed the CI change without the revert, and it failed which was good because it reproduced the problem: |
|
The iOS cross-compile job succeeds in CI now. |
| - uses: actions-rs/toolchain@v1 | ||
| with: | ||
| toolchain: stable | ||
| target: ${{ matrix.platform.target }} |
There was a problem hiding this comment.
Do not use actions-rs as it's currently unmaintained and has some deprecation warnings that mean the workflow won't work at some point. In this case just invoking rustup with run should be sufficient.
There was a problem hiding this comment.
Ah, it seems this was brought by the current config, it's fine then. I'm going to fix it later along with others, so feel free to leave them as-is!
There was a problem hiding this comment.
Thanks, I just copy/pasted from the existing config for consistency. It's a separate job because I couldn't tell if the cross tool would work on macOS from a brief look at it.
| # If this isn't specified the default is iOS 7, for which zlib-ng will not compile due to the lack of thread-local storage. | ||
| IPHONEOS_DEPLOYMENT_TARGET: 16 |
There was a problem hiding this comment.
Just curious: does this mean iOS 16 would be the minimum supported version?
There was a problem hiding this comment.
For this compilation, yes. I didn't feel like actually trying to figure out what the minimum version of iOS that zlib-ng could build for was, so I just used iOS 16 since that's the current SDK. This won't affect any users of the crate, it's just for compiling zlib-sys in CI here.
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
In #158, better support for using CMake's cross-compilation facilities was added. This made the workaround added in #110 for iOS not only unnecessary, but actively harmful, in that it runs afoul of SDK validation checks in the CMake iOS codepath.
This PR removes the workaround (reverting #110) and also adds a CI job to test an iOS cross-compile.