Description
All up there seems to two issues:
- Docs cannot be generated for iOS from non-macOS hosts because of a dependency on a binary for generating linker flags that only exists on macOS
- Errors are not being propagated from this part of the build process to rustbuild, leaving for a headscratcher
I added an aarch64-apple-ios
requirement to the docs.rs metadata in one of my crates, which caused a build failure on docs.rs. rust-lang/docs.rs#1040
Upon trying to reproduce this issue and find a fix, I hit the issue while trying to build rustc with the target aarch64-apple-ios
from an x86_64 Linux host.
$ ./x.py build --target aarch64-apple-ios
Updating only changed submodules
Submodules updated in 0.02 seconds
Finished dev [unoptimized + debuginfo] target(s) in 0.10s
error occurred: No such file or directory (os error 2)
failed to run: /.../rust/build/bootstrap/debug/bootstrap build --target aarch64-apple-ios
Build completed unsuccessfully in 0:00:00
Not ideal output. 😛
The reason this happens is quite straightforward: ios and tvos targets use the apple_sdk_base module to resolve the pre_link_args
field, and it is fallable.
The logic in the get_sdk_root
function seems a little faulty, as it does a simple check for existence of a directory from the environment variable SDKROOT
, then if that fails, it tries to run the xcrun
binary which only exists on macOS hosts. That xcrun failure is a hard failure.
As stated in rust-lang/docs.rs#1040, a workaround for at least generating documentation is to provide SDKROOT
with a path to an empty directory to iPhoneOS.platform
.
No such issue occurs on *-apple-darwin
because an entirely different codepath is taken.
I am not sure of the right course of action to fix this:
- Change ios and tvos targets to not require
pre_link_flag
s to be set, like macOS, and let build failures occur after printing a warning so the user can at least fix the issue - Add a hack for
doc
so that at least docs.rs can generate documentation for ios - Don't change this behaviour at all, but fix the error message so that cross-compiling devs won't just stare blindly at their screen asking "why me"
My preference is for the first option, and I'm quite happy to contribute a fix for it, though I would need assistance in successfully cross-compiling rustc for macOS from Linux. 😄
It is probable that this is the same issue: #42084.