Replacing `cpio -pdm` with `copyHierarchy` makes us end up with two
extra headers. I'm not sure why this happens, there's no reason why
`cpio` should miss those headers.
I noticed every time building Libsystem that there was a very slow phase
where the output consisted of many lines like `42 blocks`. This is
output from cpio and in brief testing it takes at least twice as long to
go through cpio for the simple copies we want to make. The interface is
very convenient but the performance penalty is very painful so I decided
to implement a function that emulates cpio's interface.
On my machine with a 7200 RPM HDD this speeds up the build from about
250 minutes to about 75 seconds, a factor of 200! I'm not certain the
results on modern hardware would be similarly positive so this could use
further testing.
`configd` is aliased to `apple-sdk.frameworks.SystemConfiguration` in
apple-sdk-11.0, which is the default on aarch64-darwin, but it does not
include all of the headers. This package introduces the missing
headers, which are needed to build `libresolv`.
A subsequent commit will fix libresolv to build on aarch64-darwin.
Including `TargetConditionals.h` had knock-on effects, breaking the zlib
build because `TARGET_OS_MAC` gets defined, for instance.
Defining `TARGET_OS_EMBEDDED` to be `0` if it's not defined is simpler
and maintains the default behavior so it shouldn't break any dependents.
`TargetConditionals.h` was missing several definitions, like
`TARGET_OS_TV` that are part of SDK 10.12 at least. And one that doesn't
seem to occur in any SDK afaict, `TARGET_OS_EMBEDDED_OTHER`.
I added the definitions from SDK 10.12 verbatim and defined
`TARGET_OS_EMBEDDED_OTHER` to be equal to `0`.
I think none of this works if `darwin.Libsystem` is used to build for
linux or iOS though so maybe this needs a more thorough fix?
This reverts 336d82617f because it's no
longer necessary.
If things build fine with `stdenvNoCC`, let them use that. If tools
might be prefixed, prepare for that, either by directly splicing or just
using the env vars provided by the wrapper setup-hooks.
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
I am taking the non-invasive parts of #110914 to hopefully help out with #111988.
In particular:
- Use `lib.makeScopeWithSplicing` to make the `darwin` package set have
a proper `callPackage`.
- Adjust Darwin `stdenv`'s overlays keeping things from the previous
stage to not stick around too much.
- Expose `binutilsNoLibc` / `darwin.binutilsNoLibc` to hopefully get us
closer to a unified LLVM and GCC bootstrap.
