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
Also drop diffutils from the `inherit (prevStage)` overrides in
pkgs/stdenv/linux/default.nix. Once the package lives in pkgs/by-name,
that pin gives the top-level `diffutils` attribute a source location
even though it is defined via `_internalCallByNamePackageFile`, which
nixpkgs-vet rejects (NPV-102). Dropping the pin lets the by-name
auto-definition stand on its own, at the cost of no longer reusing the
bootstrap-stage build (a stdenv-class rebuild, hence staging).
Co-authored-by: Philip Taron <philip.taron@gmail.com>
Assisted-by: Claude Code (claude-opus-4-8)
libxcrypt was built twice (xgcc and stage2). Adding it to the inherit list
at xgcc and stage2 chains it through: stage1 produces the single build,
xgcc/stage2/stage3 inherit. Total bootstrap-stage builds: 2 -> 1.
libxcrypt is build-time-only — it is needed at build time by tools that
support libcrypt-style password hashing, but its `out` is not in the final
stdenv runtime closure (glibc no longer depends on libxcrypt at runtime;
applications that need it link directly).
Safe with respect to the `disallowedRequisites` check on the final
stdenv-linux.
python3Minimal was being rebuilt at stages 3 and 4. It is used only as a
native build input (e.g. meson, glib build helpers); its outputs do not
appear in the final stdenv's runtime closure.
Inheriting from prevStage at stage3 and stage4 collapses 2 -> 1 build.
Build-only dependency, safe with respect to the `disallowedRequisites`
check on the final stdenv-linux.
autoconf269 was being rebuilt at stages 2 and 3. It is used only as a
native build input (to regenerate `configure` scripts in autotools-using
packages); its outputs never appear in the final stdenv's runtime closure.
Inheriting it from prevStage at stage2 and stage3 collapses 2 -> 1 build.
Build-only dependency, safe with respect to the `disallowedRequisites`
check on the final stdenv-linux.
nukeReferences was rebuilt at every stage where it appeared (xgcc, stage2,
stage3 — 3 redundant builds beyond stage1's initial build). It is used only
at build time (to scrub references from libidn2/libunistring at stage2),
never appears in the final stdenv's runtime closure, and its outputs are
not propagated into other final-closure derivations.
Adding it to the inherit list at xgcc, stage2, and stage3 collapses the
chain to a single stage1 build. Stage4 still produces its own nukeReferences
through the regular package set; that one is unused by the final stdenv.
Build-only dependency, so this is safe with respect to the
`disallowedRequisites` check on the final stdenv-linux.
dejagnu is never demand-built in the bootstrap closure (verified via
`nix-store --query --requisites | grep dejagnu` returning empty on
master). The override existed but the resulting derivation was never
referenced by anything stage2+ actually builds.
Verified by drv-hash equality: stdenv.drvPath is unchanged
(q2xn5647kadsgpz40xcmjssa0pmdmiwi-stdenv-linux.drv).
The override at `super.binutils-unwrapped.override { enableGold = false; }`
defined a stage1 `binutils-unwrapped` derivation that was never used:
xgcc-stage and stage2 both build their own fresh `super.binutils-unwrapped`
without inheriting from stage1, so the gold-disabled rebuild never appeared
in the build graph (verified via `nix-store --query --requisites`).
Verified by drv-hash equality: stdenv.drvPath is unchanged
(q2xn5647kadsgpz40xcmjssa0pmdmiwi-stdenv-linux.drv).
The hook was added six times — once in each of stages 1, xgcc, 2, 3, 4
(and again at the final stdenv) — to teach configure scripts about
non-x86_64 architectures. Wire it once inside stageFun instead, guarded
by `prevStage ? updateAutotoolsGnuConfigScriptsHook` so the dummy stage
(whose prevStage is the raw stub) is unaffected.
The final stdenv (built outside stageFun) keeps its explicit entry.
Eval-verified: stdenv.drvPath is unchanged from master
(q2xn5647kadsgpz40xcmjssa0pmdmiwi-stdenv-linux.drv).
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`
Rather than implementing this at the wrapper level (which has been
attempted but not merged in # 252310 and # 205031), configuring GCC
directly with --enable-default-pie is simple and matches mainstream
distribution practices. Packages that cannot build with PIE can
explicitly pass -no-pie when needed, and mostly already do
due to the prevalence of GCCs built with this flag.
Requires followup to decide what to do with "pie" flag.
Picking up where #414321 left off, we can now simplify some things by
using `pkgs.libc` or `targetPackages.libc` consistently.
Individual packages should probably continue using `stdenv.cc.libc`, for
now at least, since it is possible they are given a `stdenv.cc` with an
alternative libc, but for the treewide code, the top-level `libc`
package is preferable and easier to work with.
Co-authored-by: Tristan Ross <rosscomputerguy@protonmail.com>
This allows on-the-fly rewriting of URLs before they are passed from
fetchurl (or fetchurlBoot) to curl.
The intended use is to allow inserting company-internal mirrors, or
working around company firewalls and similar network restrictions,
without having to extensively patch across all of nixpkgs. Instead,
users can pass a function in their nixpkgs that performs the necessary
URL rewrites.
Co-authored-by: Alexander Bantyev <balsoft@balsoft.ru>
Add the same trick for gettext as for libunistring below, skipping
"checking for working iconv" which requires locales and gconv modules
(and other stuff we don't have in bootstrapTools?)
It tries to run the following check in `iconv.m4` which fails:
```c
#include <iconv.h>
#include <string.h>
int
main (void)
{
int result = 0;
/* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
provided. */
{
/* Try standardized names. */
iconv_t cd1 = iconv_open ("UTF-8", "EUC-JP");
/* Try IRIX, OSF/1 names. */
iconv_t cd2 = iconv_open ("UTF-8", "eucJP");
/* Try AIX names. */
iconv_t cd3 = iconv_open ("UTF-8", "IBM-eucJP");
/* Try HP-UX names. */
iconv_t cd4 = iconv_open ("utf8", "eucJP");
if (cd1 == (iconv_t)(-1) && cd2 == (iconv_t)(-1)
&& cd3 == (iconv_t)(-1) && cd4 == (iconv_t)(-1))
result |= 16;
if (cd1 != (iconv_t)(-1))
iconv_close (cd1);
if (cd2 != (iconv_t)(-1))
iconv_close (cd2);
if (cd3 != (iconv_t)(-1))
iconv_close (cd3);
if (cd4 != (iconv_t)(-1))
iconv_close (cd4);
}
return result;
;
return 0;
}
```
Then it assumes iconv is not there and tries to use some built-in iconv
function? idk
Resulting in following error:
```
iconv-ostream.c:311:3: error: initialization of 'void (*)(struct
any_ostream_representation *, ostream_flush_scope_t)' from incompatible
pointer type 'void (*)(struct any_ostream_representation *)' []
```
This isn't causing a build failure in other architectures because we
haven't updated bootstrapTools to gcc14, so the error isn't noticeable,
but it's there. Check https://hydra.nixos.org/build/294707390/nixlog/10
The status quo of `bash` not being interactive is frustrating for many users,
because trying to use it interactively is just messed up, and
`bashInteractive` is not intuitive and barely discoverable.
This was brought to my (and many others) attention by @stahnma in his
[talk at CfgMgmtCamp 2025](https://cfp.cfgmgmtcamp.org/ghent2025/talk/YUVUTN/),
where he highlighted this as one of the frustrations he ran into when
learning Nix.
Why this is fine:
- No reason for not making interactive the default was given in the original commit (6c6ff6f36f), but probably it was due to the increase in closure size
- The closure size only increases by 6.9MiB (19.5%) today, with the
added dependency on the store paths for readline and ncurses, which
are needed on systems in almost all cases anyways
- If somebody really needs to get a more minimal system, they can use
the newly-introduced `bashNonInteractive` instead now
- Though to apply it consistently, they'll need to do that in an
overlay like
```
final: prev: {
bash = self.bashNonInteractive;
}
```
Or alternatively using the `system.replaceDependencies.replacements`
NixOS option approach.
While there's also other such `*Interactive` packages that could use the
same treatment, `bash` is a great start.
This was already attempted before in
https://github.com/NixOS/nixpkgs/pull/151227, but was not continued for
unknown reason.
To avoid stdenv becoming bigger, all uses of bash in the (working)
stdenv's are changed to the explicitly non-interactive version here.
This commit will however still cause a mass rebuild for all packages (and reverse deps)
making use of the default bash.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 78e9caf153
result/bin/apply-formatting $NIXPKGS_PATH
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!
For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
As of late, `final: prev: …` for overlays has become more prevalent in
newer code. This is also exhibited in some code (presumably added
recently) in stdenv. This change is not about any merits or demerits of
any naming convention, but rather aims to make the nomenclature in
stdenv bootstrapping consistent to lessen confusion.
I've chosen to stick to `self: super: …` convention because:
1. It is more common in the code as it stands.
2. Using `final: prev: …` makes the code more confusing, als it causes
`prev` to be in scope alongside `prevStage`. `prevStage` actually
bears no relation to `prev` even though their naming suggests it,
making it easy to confuse them (the former is the (final) package set
of the previous stage while the latter is just the `prev`/`super` of
the overlay “chaining” on a completely fresh package set, i.e. `prev`
doesn't even relate to the previous stage's `overrides` argument).
This change also corrects a naming error in stdenv/native which had no
effect, as the variables were unused.
