sed -i 's/ webkitgtk\b/ webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/(webkitgtk\b/(webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/\.webkitgtk\b/.webkitgtk_4_0/g' pkgs/**.nix
webkitgtk is currently pointing to that specific ABI version but the
alias is going to start warning
The GCC bootstrap builds each stage with an unwrapped GCC, which needs
to correctly handle looking for libraries and headers in sysroot.
Setting the native header folder to `/usr/include` will actually cause
GCC to search `<sysroot>/usr/include`, which is the SDKROOT in nixpkgs.
The original logic was prepending to the array, but this one prepends
the array to itself, which breaks the x86_64-linux stdenv bootstrap. The
correct thing to do is build up the arguments in a temporary array and
prepend it like the original code was doing.
When using the LLVM bootstrap to build LLVM and its libraries,
overriding just LLVM to disable tests during the first build doesn’t
seem to work. This stage name should remain stable, so check for it and
disable tests when building in it.
When compiler-rt targets Darwin, it is built with `-target`, which
causes clang to try to invoke `ld` without a target prefix (e.g., it
will try to exec `ld` instead of `x86_64-apple-darwin-ld` on a
cross-build to x86_64-darwin). Specifying `--ld-path` overrides that
behavior, allowing it to find the appropriate cross-linker.
The first build of compiler-rt in the LLVM bootstrap is build without
libc++ being available, which causes support for the `-g` flag to be
detected incorrectly on Darwin. Overriding the check by specifying that
it’s usable allows the first build of compiler-rt to succeed.
compiler-rt supports specifying the SDK path and version, so do that to
avoid needing to include `xcrun` as a native build input, which
simplifies the bootstrap.
Instead of using overrides in the stdenv bootstrap, Darwin will be
relying on the LLVM bootstrap to build compiler-rt. The only special
handling it needs is to use a stdenv with a bootstrap SDK instead of the
default one (to avoid infinite recursions).
While the Darwin stdenv bootstrap sets up its own clang wrappers and
doesn’t provide these wrappers in the final stdenv, it does use them
indirectly via the LLVM bootstrap to build LLVM and its libraries.
Note on using the system libunwind: It is possible to build and use the
LLVM libunwind on Darwin, but using the system by default one ensures
everything is using the same unwinder.
Swift releases are associated with particular Darwin SDK versions. They
don’t _have_ to use that version, but it makes sense to use that version
by default. The deployment target is set to the supported Swift minimum
versions. Unlike C and C++, Swift requires you to availability
annotations, so propagating a newer SDK should be safe.
libarclite is needed to support ARC on very old deployment targets
(10.10 and older). None of these deployment targets are supported
deployment targets in nixpkgs, especially for Swift. This removes the
need to package the command-line tools executables.
Swift’s build makes a few assumptions about how the SDK is set up that
are not true anymore with the new SDK. Fix it to find the SDK at
`$SDKROOT` and copy additional stubs it needs to bootstrap.
