cctools-llvm is a replacement for cctools that replaces as much of cctools with equivalents from LLVM that it can reasonably do. This was motivated by wanting to reduce dependencies on cctools, which are updated infrequently by upstream.
To provide a motivating example, the version of `strip` included in cctools cannot properly strip the archives in compiler-rt in LLVM 15. Paths are left to bootstrap tools, resulting in failed requisites checks in the final stdenv build. Since `strip` needs replaced, the opportunity was taken to replace other provided they are functional replacements.
Note: This has to be done in cctools (or some equivalent) because some derivations (noteably LLVM) use the bintools of the stdenv directly instead of going through the wrapper.
The following tools from LLVM are not used in this derivation:
* LLD - not fully compatible with ld64 yet and potentially too big of a change;
* libtool - not a drop-in replacement yet because it does not support linker passthrough, which is needed by xcbuild;
* lipo - crashes when running the LLVM test suite;
* install_name_tool - fails when trying to build swift-corefoundation; and.
* randlib - not completely a drop-in replacement, so leaving it out for now.
If other incompatabilities are found, the tools can be reverted or made conditional. For example, cctools `strip` is preferred on older versions of LLVM (which lack the compiler-rt issue) or when cctools itself is a new enough version because `llvm-strip` on LLVM 11 produces files that older verions of `codesign_allocate` cannot process correctly.
One final caveat/note: Some tools are not duplicated or linked from cctools-port. The names of the tools and which ones were linked was determined based on what is provided upstream in Xcode and is installed on macOS system.
For reasons explained in the commit contents, in order to build the
native gnat package for x86_64-darwin, the native gnatboot package for
x86_64-darwin must have access to both the Clang integrated assembler
and the cctools GNU assembler for that platform. This commit creates a
package with both of those assemblers that x86_64-darwin gnatboot can
then be wrapped with.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
- Use the 11.0 SDK instead of the 10.12 one on x86_64-darwin;
- Use `NIX_CFLAGS_COMPILE` and `NIX_LDFLAGS` to pass flags to the
compiler instead of patching the Xcode project files; and
- Use xcbuild to build the project.
- Introduce `preLibcCrossHeaders` to bootstrap libgcc and compiler-rt
the same way.
- Organize LLVM bintools as `bintools{-unwrapped,,NoLibc}` for
consistency with GNU Binutils and Apple's cctools.
- Do Android changes for all `llvmPackages` for consistency.
- Improve the way the default GCC and LLVM versions are selected.
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.
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.
The only remaining use-case for cf-private are symbols that are not
available in the opensource build. This generally solved the problem
because of it's setup-hook.
CoreFoundation is included by the stdenv, moving the decision of what
version should be used there makes it possible to override it entirely
rather then prepending flags like cf-private does which can be
unreliable.
