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.
