The first build of compiler-rt in the LLVM bootstrap is build without
libc++ being available, which causes support for the `-g` flag to be
detected incorrectly on Darwin. Overriding the check by specifying that
it’s usable allows the first build of compiler-rt to succeed.
compiler-rt supports specifying the SDK path and version, so do that to
avoid needing to include `xcrun` as a native build input, which
simplifies the bootstrap.
Instead of using overrides in the stdenv bootstrap, Darwin will be
relying on the LLVM bootstrap to build compiler-rt. The only special
handling it needs is to use a stdenv with a bootstrap SDK instead of the
default one (to avoid infinite recursions).
While the Darwin stdenv bootstrap sets up its own clang wrappers and
doesn’t provide these wrappers in the final stdenv, it does use them
indirectly via the LLVM bootstrap to build LLVM and its libraries.
Note on using the system libunwind: It is possible to build and use the
LLVM libunwind on Darwin, but using the system by default one ensures
everything is using the same unwinder.
Using the bootstrap stdenv avoids an infinite recursion from xcbuild
depending on libxml2 depending on xcrun from xcbuild, which is
propagated by the non-bootstrap stdenv.
Using the bootstrap stdenv avoids an infinite recursion from xcbuild
depending on libpng depending on xcrun from xcbuild, which is propagated
by the non-bootstrap stdenv.
With this workaround enabled, CMake looks for SDK headers and libraries
in `${SDKROOT}/var/empty`, which ensures it will not find them.
Disabling the workaround in just this case allows CMake’s SDK support to
work with the SDKs in nixpkgs while still not including other, impure
paths in its search paths.
Without this change, all Darwin platforms mangle to the same suffix
salt. That is normally not an issue because build = host should mean a
non-cross build, but it causes issues on Darwin with static builds
because `DEVELOPER_DIR_FOR_BUILD` and `DEVELOPER_DIR` will refer to
different SDKs but mangle to the same `DEVELOPER_DIR` with suffix salt.
The fix is to mangle static builds differently from non-static ones on
Darwin, which allows building for a static Darwin target on a
same-architecture Darwin host. This fix is applied only to Dariwn
because the issue does not appear to affect other platforms.
It is unusual to invoke a wrapped compiler without setting
`DEVELOPER_DIR`, but it can happen when a user adds a compiler to their
installed packages or when a package intentionally invokes the compiler
without an environment (such as the GHC binary packages).
Some compilers may know to check these paths when `SDKROOT` is set, but
it’s not assumed they do. `SDKROOT` is instead derived from the
`DEVELOPER_DIR`, and `NIX_CFLAGS_COMPILE` is set up with the sysroot and
necessary framework and include search paths.
This is a new packaging of the Darwin SDK. Instead of splitting
libraries and frameworks into separate packages, it provides a single
package for the whole SDK.
# Features
- Vendored files are removed from the SDK. There are 50+ different
packages that are vendored by upstream (depending on the version);
- Components that are built in nixpkgs (either from upstream or from the
source releases) are also removed. If they need to be included by
default, they are propagated;
- A single SDK pattern is used to package all SDKs, and scripts are
provided to aid updating the SDK version and its source release
versions. This makes adding new SDKs much easier;
- SDK overrides are handled by adding the SDK version you require. If
multiple SDKs are present, only the newest is used. It is possible to
have different SDKs for each of build, host, and target platforms;
- Private headers are no longer provided by default unless you use the
SDK’s `privateFrameworksHook` to add them. It does the right thing
when multiple SDKs are in your inputs;
- Source releases for the SDK version are available via a passthru
`sourceRelease` function. This is mostly useful for getting private
headers for building source releases in the darwin attrset; and
- The same versions of propagated components are used on both platforms
(e.g., the same libresult, libiconv, etc).
See `pkgs/by-name/ap/apple-sdk/README.md` for details on how the SDK
derivation is structured and how to update it.
libsbuf is required by some of the source release updates that will
be done. Unfortunately, it is only available on macOS 14 and newer, and
there is no source release available currently.
This is a port of libsbuf from FreeBSD, which appears to be the origin
of the header provided in the 14.x SDK. It provides the same ABI as the
system dylib and same API as the the SDK header while being available on
all supported deployment targets in nixpkgs.
Note: This package is not based on libsbuf from the FreeBSD package set
in nixpkgs because: it doesn’t build on Darwin, and using it would pull
many FreeBSD packages into the Darwin bootstrap, which is undesirable.
This is a replacement for the family of `appleDerivation` functions
currently used. It is patterned after the `mkDerivation` used in the BSD
package sets. It also provides additional support for using Meson to
build source releases.
This hook is used by source releases that build with Meson to assert
that the Xcode project has not changed since the previous release. This
is meant to be a check to force those updating source release packages
to make sure they have incorporated any changes that were made to the
Xcode project into the Meson build.
The new Darwin SDK pattern relies on an effectively empty, stub libc
implementation. The actual libSystem to be linked is located dynamically
based on the active SDK for the target. Independent build, host, and
target SDKs are all supported by Darwin.
The stub libSystem contains empty `include` and `lib` folders to avoid
warnings from wrappers that add those paths unconditionally, which can
turn into errors when a package is building with warnings-as-errors.
While it would be nice if a fallback libc could be provided, SDK headers
are not compatible between framework versions. Providing a fallback
risks mixing headers from different frameworks, which can result in hard
to diagnose errors involving semicolons or other punctuation.
Adding the hook allows the deployment target to be changed without
having to mess with the stdenv. The can also be propagated, which is
useful for libraries that have a minimum deployment target higher than
the default in nixpkgs. In that case, they can propagate the hook to
ensure library users are not targeting an unsupported version.
Packages propagated by the SDK need to use a stdenv that does not
propagate anything. Otherwise, an infinite recursion will result when
building those packages.
For consistency, all source releases should use the bootstrapStdenv.
This effectively disables the native GitHub codeowners feature
and enables the new alternate codeowners mechanism introduced in
https://github.com/NixOS/nixpkgs/pull/336261
This means that:
- We can now declare users without write access as code owners!
- Targeting the wrong branch won't trigger mass pings anymore!
Randy Eckenrode