`${stdenv.cc.libc}/lib/libSystem.B.dylib` does not exist and not existed
for as long as I have used nixpkgs. Since `/usr/lib/libSystem.B.dylib`
is already linked via text-based stubs, continue relying on those.
libunwind is unnecessary on Darwin because it is included in the SDK,
but setting libunwind to `null` would cause evaluation errors.
Additionally, some packages expect to locate libunwind via pkg-config.
Set the top-level libunwind to the Darwin compatibility package, so
those packages can find it and use it.
Darwin’s libc is a stub that does nothing but avoid unwanted compiler
and linker warnings. The actual libc is located dynamically based on the
SDK. To support cross-compilation, the SDK is located based on platform:
- `DEVELOPER_DIR_FOR_BUILD` - build platform;
- `DEVELOPER_DIR` - host platform; and
- `DEVELOPER_DIR_FOR_TARGET` - target platform.
Most Darwin source releases vendor private headers in a separate
derivation and add them to `NIX_CFLAGS_COMPILE` (to avoid propagating
them in static builds). Adopt this pattern for consistency with the
other source releases.
The SDK library path is normally add by the ld wrapper, but ld64 is
being used unwrapped in this check phase. Ensure it can find the
requires SDK stubs by passing them via the clang wrapper.
Many packages need only libtool from cctools, which is different from
GNU libtool (commonly used with other autotools), so it can’t be
provided by default with the Darwin bintools. Providing it as a separate
output allows packages to use cctools’s libtool without pulling other
tools they may not want.
The patch adding support for `__ENVIRONMENT_OS_VERSION_MIN_REQUIRED__`
to clang has been backported to all versions of clang in nixpkgs (except
for clang 12), allowing this workaround to be dropped.
While it would be nice if this could be split, there are too many
changes as part of the cleanup and improvements, including:
- Refactoring all propagated packages into functions that can be used to
ensure that packages are propagated only at the expected stages;
- Using a sanity-checking merge function to ensure that packages are
only propagated by one of the above functions;
- Reducing the number of Python builds during the bootstrap to one;
- Removing the extra sysctl stage;
- Using the LLVM bootstrap to build LLVM, clang, libc++, etc;
- Propagating llvmPackages_<version> in the final stdenv, so that
packages needing that version specifically don’t have to rebuild it;
- Bootstrapping with the new Darwin SDK; and
- Reducing the overall number of paths build during a bootstrap by ~33%.
Using the bootstrap stdenv avoids an infinite recursion from xcbuild
depending on zlib depending on xcrun from xcbuild, which is propagated
by the non-bootstrap stdenv.
macOS ships with several stubs in `/usr/bin` that invoke `xcrun` to run
the tools from the active SDK. When `/usr/bin` is in `PATH`, this will
cause `xcrun` from xcbuild to invoke itself over and over. Filtering
`/usr/bin` from `xcrun`’s search path prevents this from happening.
xcbuild determines the SDK dynamically, so overriding the `sdkVer` no
longer works. If packages want to change the SDK, they need to add one
of the SDK packages to their inputs.
Take advantage of the new Darwin SDKs to dynamically determine SDK
information such as path, version, and binaries (via `xcrun --find`).
This is accomplished by relying on the existance of `DEVELOPER_DIR`,
which the SDK will set up in nixpkgs.
Using the bootstrap stdenv avoids an infinite recursion from xcbuild
depending on ncurses depending on xcrun from xcbuild, which is
propagated by the non-bootstrap stdenv.
Randy Eckenrode