With -platform_version flags for two distinct platforms,
this writes a LC_BUILD_VERSION header for each.
The motivation is that this is needed for self-hosting with lld as linker
after D124059.
To create a zippered output at the clang driver level, pass
-target arm64-apple-macos -darwin-target-variant arm64-apple-ios-macabi
to create a zippered dylib.
(In Xcode's clang, -darwin-target-variant is spelled just -target-variant.)
(If you pass -target arm64-apple-ios-macabi -target-variant arm64-apple-macos
instead, ld64 crashes!)
This results in two -platform_version flags being passed to the linker.
ld64 also verifies that the iOS SDK version is at least 13.1. We don't do that
yet. But ld64 also does that for other platforms and we don't. So we need to
do that at some point, but not in this patch.
Only dylib and bundle outputs can be zippered.
I verified that a Catalyst app linked against a dylib created with
clang -shared foo.cc -o libfoo.dylib \ -target arm64-apple-macos \ -target-variant arm64-apple-ios-macabi \ -Wl,-install_name,@rpath/libfoo.dylib \ -fuse-ld=$PWD/out/gn/bin/ld64.lld
runs successfully. (The app calls a function f() in libfoo.dylib
that returns a const char* "foo", and NSLog(@"%s")s it.)
ld64 is a bit more permissive when writing zippered outputs,
see references to "unzippered twins". That's not implemented yet.
(If anybody wants to implement that, D124275 is a good start.)
ld64 allows this, but it's not used for anything as far as I can tell. So let's not allow it for now.