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.
- boost 167 removed on staging-next (7915d1e03f) × boost attributes are inherited on staging (d20aa4955d)
- linux kernels were moved to linux-kernels.nix on staging-next (c62f911507) × hardened kernels are versioned on staging (a5341beb78) + removed linux_5_12 (e55554491d)
- conflict in node-packages – I regenerated it using node2nix from nixos-unstable (does not build on staging)
The current build works by linking against CoreSymbolication in
/System/Library/PrivateFrameworks. This is impure and doesn't work in
newer versions of macOS.
See https://github.com/NixOS/nixpkgs/issues/128576
We could use our own libc++ here, but it is probably best to use the
provided one to ensure consistency. This fixes some C++ programs when
running aarch64-apple-ios-clang++.
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.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Without this change `as` on `aarch64-darwin` is defunct:
```
$ /nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/bin/as -v
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/bin/as: assembler (/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/arm64/as or /nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/arm64/as) for architecture arm64 not installed
Installed assemblers are:
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/ppc64/as for architecture ppc64
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/x86_64/as for architecture x86_64
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/ppc/as for architecture ppc
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/i386/as for architecture i386
/nix/store/g11xba8ch20zndaf32hfnap46z47b5k3-cctools-port-949.0.1/libexec/as/arm/as for architecture arm
```
Apple defaults to Clang in all cases from what I see, but nixpkgs prefers `cctools`: #51881.
