The current hook specifies the path to the framework library, but
nixpkgs does not actually provide the library when linking against the
system framework. It provides a text-based stub (`.tbd`) instead. ld64
will find the stub and use it, but lld will not when the full path is
specified. Both linkers work if the extension is included, so do that
for compatibility with both. This fixes using lld with CoreFoundation
(e.g., to support LTO on Darwin).
This can result in swift-corefoundation being included even when a
derivation uses `apple_sdk_11_0.stdenv` directly, which may result in
hard to debug compiler errors (unless you just happen to know cryptic
compiler errors means the 10.12 and 11.0 SDKs have been mixed).
Contrarily to the other frameworks, System framework's TBD file
is a symlink pointing to `${MacOSX-SDK}/usr/lib/libSystem.B.tbd`.
This produces an error when using the framework, as:
1. The original file is not copied into the output directory
2. Even if it was copied, the relative path wouldn't match
Resulting in the symlink being broken and the linker failing when
trying to link `-framework System`.
The fix applied consists in replacing the symbolic link with the
actual file, as this is easier than fixing the link and doesn't
seem to produce any side effects.
The SDK was missing SDKSettings files. This is usually not a problem for
Nix builds, because we generate our own fake SDK structure when
necessary (in xcbuild), but not having these files blocks using the
upstream Apple SDK in tooling such as gen-frameworks.py.
This reverts commit 511f21df7c.
In apple_sdk_11_0, the xpc package contains only headers that are
already part of libsystem, so this change did nothing.
For Swift and `-fmodules`, this actually caused an error, because
there was now a duplicate module in the search path.
Some packages like `bazel-watcher` seems to have broken after
9dc3b14859
Where `xpc` was removed from `IOSurface` dependencies.
`CoreServices` were pulling `xpc` via `IOSurface` and so `Security`
didn't break. Now explicit dependency on `xpc` is needed to avoid
errors like
```
In file included from __main__/external/com_github_fsnotify_fsevents/go_1_10_after.go:6:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:29:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43:
In file included from /nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/Security.h:87:
/nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/SecCode.h:35:10: fatal error: 'xpc/xpc.h' file not found
^~~~~~~~~~~
```
Should help with https://github.com/NixOS/nixpkgs/pull/203519
Stdenv on aarch64-darwin pulls in (bootstrap-stage4) objc4, unlike
x86_64. However derivations that otherwise depend on objc4 would use a
a different objc4 derivation on top of the final stdenv.
Because this library defines an LLVM module, having multiple instances
of it in the import path will interfere with builds.
