The final stage asserted
assert prevStage.libiconv == prevStage.darwin.libiconv;
On Darwin `libiconv` is `darwin.libiconv`, so this compares a value with
itself. Nix does not notice: `eqValues` short-circuits only on pointer
identity of the two value slots, and these are two slots that resolve to
one attribute set. It therefore falls through to the derivation case,
which compares `outPath`.
`lib.extendDerivation` guards `outPath` behind the derivation's validity,
which reads `config.allowUnfree`, so the assertion demanded a `config`
option while the package set was still being assembled. When `config` is a
function it is passed `pkgs`, and the loop closes:
(import <nixpkgs> {
system = "aarch64-darwin";
config = { pkgs, lib, ... }: { allowUnfree = lib.isAttrs pkgs; };
}).config.allowUnfree
failed with an infinite recursion on Darwin while evaluating on Linux,
whose stdenv never forces a derivation that early. It now evaluates on
both.
Keep checking the invariant, from `tests.stdenv` instead. By then the
package set is complete, so forcing `outPath` is just a read.
The other twelve assertions in the stage read `passthru` and
`stdenv.cc.cc`, which are ungated, and stay where they are.
Assisted-by: claude-code with claude-opus-5[1m]-high
The dispatcher now constructs local bootstrap stages directly, so their target is represented entirely by localSystem. Remove the redundant crossSystem arguments and equality assertions from each local stage implementation.
Assisted-by: codex with gpt-5.6-sol-high
it would be as simple as setting `strictDeps = true` and
`buildInputs = [ bashNonInteractive ]` except this package is used
during the bootstrap of `stdenv`: this method of manually patching
seems to be the least complex way to get correct behavior while
avoiding cyclic when deriving `stdenv` itself.
successfully built the following, from x86_64-linux:
- `gnu-config`
- `pkgsCross.aarch64-multiplatform.buildPackages.gnu-config` (equivalent)
- `pkgsCross.aarch64-multiplatform.gnu-config`
- `pkgsCross.musl32.gnu-config`
- `pkgsMusl.gnu-config`
- `pkgsStatic.gnu-config`
- `pkgsi686Linux.gnu-config`
successfully eval'd `gnu-config` for the following systems:
- `aarch64-darwin`
- `aarch64-freebsd`
- `aarch64-linux-musl`
- `aarch64-linux`
- `x86_64-cygwin`
- `x86_64-darwin`
- `x86_64-freebsd`
- `x86_64-linux-musl`
- `x86_64-linux`
This is the libc++ from the bootstrap. Once the past the xclang stage,
the bootstrap uses the system libc++. Unfortunately, it doesn’t seem to
work with the bootstrap tools.
This change allows `overrideScope` to work correctly outside of the
bootstrap. Packages have to be overriden manually with the final
`libllvm` to make sure any overrides to `libllvm` are picked up. The
workaround is being dropped because rebuilds are expected.
Note that the top-level `clang` is being dropped because it is an alias
for `llvmPackages.clang`. Not overlaying it preserves the expected
behavior if someone overlays `llvmPackages.clang` in their config (which
is that the top-level one will be the same derivation as the overlay).
The LLVM derivation defines `llvm` as an alias for `libllvm`. The same
is true for `clang-unwrapped` and `clang`. Doing the overrides this way
allows overrides to work as expected (especially at the end).
It’s not ideal that the version has to be hardcoded, but right now it’s
not recorded in any configuration accessible from the bootstrap outside
of a package set. If that changes in the future, this should be changed
to get `llvmVersion` from that source.
Allows having alternate hashed mirrors as fallbacks. Useful in case the
default hashed mirror is not accessible or doesn't have everything
needed.
Co-authored-by: Johan Herland <johan.herland@tweag.io>
Co-authored-by: Yuriy Taraday <yuriy.taraday@tweag.io>
Co-authored-by: Alexander Bantyev <balsoft@balsoft.ru>
Since #420382, we set an absolute default CLANG_RESOURCE_DIR for LLVM
versions >= 21, which breaks the bootstrap tools because the absolute
path was removed by nuke-ref while building and isn't there while
bootstrapping.
Pass -resource-dir explicitly while testing Clang to make it work.
Fix this config name for consistency with non-bootstrap platform config.
This also fixes a build failure of the bootstrap tools on
aarch64-darwin, where a test in LLVM 21 assumes it's spelt arm64, not
aarch64.
Also saves on having to rebuild LLVM just for bootstrap tools, now that
the config is consistent.
Not having the CUPS headers in the sysroot causes problems for Swift’s
module importer when it tries to import AppKit, which depends on CUPS
headers. The module importer is effectively an unwrapped Clang, so the
headers need to be symlinked there instead of just propagated.
