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.
We were previously using a dummy wrapper for dsymutil. This meant that
debug symbols were not getting generated when dsymutil was otherwise
available. This should fix that issue & provide a real dsymutil from
llvm.
Fixes#52148.
Since at least d7bddc27b2, we've had a
situation where one should depend on:
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables,
regardless of the host platform, at run time.
and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:
- `binutils` is indeed unconditionally GNU Binutils
- `binutils-raw`, which previously served that role, is gone.
so that the correct usage will be enforced going forward and everything
is simple.
N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
- Give cctools a dev output for the headers
- Update Libsystem to grab the headers from that dev output
- Don't include the headers in Darwin binutils, just as GNU Binutils no
longer does.
This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
We want platform triple prefixes and suffixes on derivation names to
be used consistently. The ideom this commit strives for is
- suffix means build != host, i.e. cross *built* packages. This is
already done.
- prefix means build != target, i.e. cross tools. This matches the
tradition of such binaries themselves being prefixed to disambiguate.]
Binutils and cctools, as build tools, now use the latter
- No more *Cross duplication for binutils on darwin either.
`cctools_cross` is merged into plain `cctools`, so `buildPackages`
chains alone are used to disambiguate.
- Always use a mashup of cctools and actual GNU Binutils as `binutils`.
Previously, this was only done in the native case as nobody had
bothered to implement the masher in the cross case. Implemented it
basically consisted of extending the wrapper to deal with prefixed
binaries.
Shea Levy