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.
Clang should find the Swift overlay, but clang in nixpkgs does not
include any path under `<sysroot>/usr` in its search paths unless that
path is added manually as a normal search path (as done here).
Curiously when building a cross compiled riscv64 GHC, the libraries (for
the target) turn out way bigger than when building a riscv64 cross
compiler. Profiling libraries are not necessary for bootstrapping GHC,
so we can disable them for now. We may want to revisit this condition,
though, once we have a native bootstrapping path for riscv64-linux set
up.
https://github.com/NixOS/nixpkgs/pull/328380 updated `gcc11` from
`11.4.0` to `11.5.0` but the darwin patch was not ready then. Let's
update it in hopes that it fixed `darwin` build.
These will still be available in the Git history if anyone wants to
try resurrecting a source‐based OpenJDK bootstrap in the future. In
the meantime they’re just confusing to have around unreferenced.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This reverts commit 019d091938.
My comments from the PR (which I only saw after it was merged):
> I'm not convinced this is a good idea — compiler authors turn things
> into errors for a reason, and as a distribution we have our part to
> play in getting problematic things fixed. It's fine to disable the
> errors for packages where it's not reasonably possible to get them
> fixed, but doing it globally means even packages that would be
> simple to fix properly don't get fixed.
> To expand a bit, the problem with this sort of thing is that it's
> very difficult later to tell when it can be removed. By setting this
> globally instead of setting it for individual packages that need it,
> we're effectively stuck with it forever, because it's impossible to
> tell if removing it is going to break any packages. If we mark
> packages individually, it's very easy to tell in future when those
> markings can be removed.
>
> This isn't a theoretical concern: something similar was done for
> pkgsMusl — some compatibility headers were added globally, instead
> of fixing individual affected packages, and now, even though we've
> discovered that the presence of those headers actually causes
> problems for other packages, it's impossible to know what the
> fallout would be of removing it. Let's not repeat this mistake.
So let's revert now, before it's too late.
Ideally we don't want to use bintools.bintools and also not really
encode knowledge of what is wrapped and what not in our GHC derivation.
Unfortunately, not all tools are part of the wrapper derivation as well.
This should be gradually improved (e.g. in the case of the darwin tools
and strip).
Some GHC bindists have a normal `$out/lib` directory which contains
symlinks to all core libs. Because it is a normal lib directory, the
bintools setup hook will pick up on it and cause ld to pass the
appropriate -L and -rpath flags. We do not want this to happen,
especially in the case of the stage2 compiler. Not only will the final
ghc have an unnecessary reference (and thus increased closure size) to
the binary ghc, but the extra libraries in the rpath mess with the rts
and cause e.g. segfaults in GHCi.
Unfortunately, there is no way to prevent this. It is a fundamental flaw
in the cc and bintools wrappers that they do not actually distinguish
between the roles of dependencies (build, host, target). Instead
the mangleVar* function will translate the dependencies split up by
roles into platforms. This means that the wrappers can't distinguish
between depsBuildBuild and depsHostTarget (== buildInputs) when natively
compiling. As long as we are natively compiling the wrappers will put
the stage0 ghc (be it in depsBuildBuild, nativeBuildInputs etc.) into
the linker flags of the final ghc.
The solution is to sidestep the issue. We just had ghc in depsBuildBuild
to have it added to PATH. GHC itself will pass the appropriate linker
flags if necessary. To avoid the setup hooks picking up on the GHC
libraries we just don't put it into depsBuildBuild or any other
dependency list. Since the GHC build system accepts the GHC binary via
an absolute path, we don't even need to add the stage0 GHC to PATH.
