Darwin uses the system unwinder, which is based on the LLVM unwinder.
While it’s mostly API-compatible with libunwind, some packages expect to
find it using `pkg-config`. This package provides a compatible file to
allow those packages to use the system unwinder on Darwin.
The bootstrap tools linker sometimes crashes when trying to link the
sqlite3 tests, which causes the bootstrap Python not to have the sqlite3
module. This causes the freezegun module to fail to build later in the
bootstrap. Using the 11.0 SDK fixes the problem.
Upstream Python supports building with a newer SDK and back-deploying,
so this change should not negatively affect users on pre-11.0 releases.
configd is an alias for the SystemConfiguration framework, which is now
always part of the SDK. Removing this parameter because it effectively
does nothing now, which could be misleading to users.
configd is an alias for the SystemConfiguration framework, which is now
always part of the SDK. Removing this parameter because it effectively
does nothing now, which could be misleading to users.
Change the adapter to add the requested SDK to the target’s build
inputs. Note that only the “11.0” (i.e., 11.3) and 12.3 SDKs are
supported. This adapter is retained for compatibility. The preferred way
to override the SDK is to add it to the appropriate inputs directly.
`${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.
