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
Starting from glibc 2.34, all functionality previously implemented in
libpthread, libdl, libutil and libanl are now integrated into libc.
https://lists.gnu.org/archive/html/info-gnu/2021-08/msg00001.html
As loongarch64 support was merged into glibc after 2.34, libutil.so is
no longer in there, thus breaking bootstrap.
https://github.com/loongson-community/discussions/issues/29
libdl is not removed because bash still links against it, and libpthread
is not removed because xgcc depends on it to build libatomic.
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 b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
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
`isl` is only needed to support `gcc` transformations enabled by
`-fgraphite*` options. Packages do not usually use those flags. None of
the bootstrap packages use it.
`nixpkgs` does not use up-to-date `isl` for `gcc` either. Let's drop
`isl` dependency from the bootstrap binary seed.
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.
Fix#53753.
Information on llvm version support gleaned from
6609892a2d68e07da3e5092507a730
Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
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.
