Support "zippered" macOS binaries

[madsmtm]

Dynamic libraries on macOS can be built in a way that allows loading them when running under Mac Catalyst as well. This is similar in spirit to universal binaries, but technologically different in that only a single binary and architecture is actually built, which allows for a lot of code sharing.

This can be used in Xcode when creating XCFramework bundles, and is underpinned by the the -darwin-target-variant flag in Clang - but that's the only official docs I could find on it. I did find this note though that explains the details really well.

If we wanted to support this in rustc, there's two questions that need answering:

• How does the user activate it? A separate triple? An extra commandline flag?
• How does the user detect this mode of compilation in their code? cfg(all(target_os = "macos", target_abi = "macabi"))? target_abi = "zippered"?

Opening this issue to have a place to refer back to, I'm undecided whether it's worth the effort to try to support, would like to see a concrete use-case first (if you know of one, please comment below!)

@rustbot label O-ios O-macos C-feature-request A-targets

[bjorn3]

How does the user detect this mode of compilation in their code? cfg(all(target_os = "macos", target_abi = "macabi"))? target_abi = "zippered"?

According to the document you linked, clang pretends the target is macOS and there is no reference to a way for the code itself to detect it is a zippered build.

[madsmtm]

I just submitted rust-lang/compiler-builtins#794 (EDIT: now #138944), in which it could be useful to have a cfg!(zippered), for optimization purposes. But that's also the only thing I know of that will require it, it's a very low-level detail in std where we could provide the flag via. bootstrap instead, and the perf gains are very, very slim. So probably fine to not have a way to detect zippered builds at compile-time.

Regarding activating it, I think it'd be enough to have some sort of -Zzippered=ios-macabi; the architecture has to stay the same (so an extra --target would be overkill), and the iOS version could be determined from IPHONE_DEPLOYMENT_TARGET like we do today.