boring-sys: Don't use CMake cross-compilation for macOS->iOS - #187
Conversation
|
Thanks for the PR. Could you explain what it fixes? Maybe show an example of a broken build with the current code? |
|
You can see one example in this log after fixing the CI to test cross-compilation more thoroughly (#188). In this case the assembly sources end up getting built for iOS devices rather than iOS simulators, presumably because CMake assumes you'll set all of the relevant cross-compilation properties if you're going to use any of them. But for toolchains that natively support multiple targets, this just makes things worse. (Honestly, I don't think this sort of policy should be happening here at all; it should be in the |
|
Citation from the CMake docs themselves:
|
|
Sorry I had other yaks to shave these last few days but I'll review these tomorrow and so far I don't see a reason not to merge those changes. |
|
No worries, that was less a "hey, pay attention to me" and more "I found a citation to support this, let me put in the PR for posterity"! |
|
I fixed the failing clippy lint in a separate PR so you can just rebase yours for CI to go green. |
(or macOS->macOS)
97f1a72 to
51a6d44
Compare
Building boring-sys for `aarch64-apple-tvos` / `aarch64-apple-tvos-sim` currently fails. `target_os = "tvos"` is unhandled at five places in the build script, and the failures are silent rather than loud: - `should_use_cmake_cross_compilation` falls through to `_ => true`, so a macOS -> tvOS build takes the generic cross-compilation path instead of the Xcode path added in cloudflare#187. - `CMAKE_PARAMS_APPLE` has no tvOS triples, so `cmake_params_apple` returns `&[]`. - The `target_os` match in `get_boringssl_cmake_config` has no `tvos` arm and ends in `_ => {}`, so with the empty params above no `CMAKE_OSX_SYSROOT` is ever set and CMake builds BoringSSL for the host macOS instead of the tvOS SDK. - `get_extra_clang_args_for_bindgen` has no `tvos` arm, so bindgen reads host macOS headers instead of the tvOS SDK sysroot. - `get_cpp_runtime_lib` misses `tvos`, which then matches `_ if config.unix` and links `stdc++` rather than `c++`. Add tvOS to each. `CMAKE_MACOSX_BUNDLE=OFF` matches the existing iOS entries and is required -- with the default `ON`, CMake's install step for BoringSSL's `bssl` host tool fails. No bitcode cflag for tvOS: bitcode was deprecated in Xcode 14 and the tvOS SDK never wants it, so the new arm is a plain `cmake_params_apple` loop like the `macos` one rather than being folded into the `ios` arm. `x86_64-apple-tvos` is included in the table for completeness even though it is a tier 3 target that needs `-Z build-std`; the mapping costs nothing and is what such a build would need. `arm64e-apple-tvos` is omitted, matching the table's existing treatment of arm64e. Cover both tvOS targets in the `test` job matrix alongside the existing iOS entries. That job builds with `--tests`, so the linker runs and verifies the cross-compilation -- which is what catches the `stdc++` / `c++` mistake above. `x86_64-apple-tvos` is left out because `rustup target add` has no prebuilt std for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Building boring-sys for `aarch64-apple-tvos` / `aarch64-apple-tvos-sim` currently fails. `target_os = "tvos"` is unhandled at five places in the build script, and the failures are silent rather than loud: - `should_use_cmake_cross_compilation` falls through to `_ => true`, so a macOS -> tvOS build takes the generic cross-compilation path instead of the Xcode path added in #187. - `CMAKE_PARAMS_APPLE` has no tvOS triples, so `cmake_params_apple` returns `&[]`. - The `target_os` match in `get_boringssl_cmake_config` has no `tvos` arm and ends in `_ => {}`, so with the empty params above no `CMAKE_OSX_SYSROOT` is ever set and CMake builds BoringSSL for the host macOS instead of the tvOS SDK. - `get_extra_clang_args_for_bindgen` has no `tvos` arm, so bindgen reads host macOS headers instead of the tvOS SDK sysroot. - `get_cpp_runtime_lib` misses `tvos`, which then matches `_ if config.unix` and links `stdc++` rather than `c++`. Add tvOS to each. `CMAKE_MACOSX_BUNDLE=OFF` matches the existing iOS entries and is required -- with the default `ON`, CMake's install step for BoringSSL's `bssl` host tool fails. No bitcode cflag for tvOS: bitcode was deprecated in Xcode 14 and the tvOS SDK never wants it, so the new arm is a plain `cmake_params_apple` loop like the `macos` one rather than being folded into the `ios` arm. `x86_64-apple-tvos` is included in the table for completeness even though it is a tier 3 target that needs `-Z build-std`; the mapping costs nothing and is what such a build would need. `arm64e-apple-tvos` is omitted, matching the table's existing treatment of arm64e. Cover both tvOS targets in the `test` job matrix alongside the existing iOS entries. That job builds with `--tests`, so the linker runs and verifies the cross-compilation -- which is what catches the `stdc++` / `c++` mistake above. `x86_64-apple-tvos` is left out because `rustup target add` has no prebuilt std for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(or macOS->macOS)
Fixes the iOS build.