0938316e05 (commitcomment-63005097)
Resulting binaries are identifical according to diffoscope
(other than embedded /nix/store/.../ paths).
FWIW, going back through versions we've packaged, the most recent
instance where these flags produced differing outputs was in 7.6.8
(comparing $out's only, FWIW).
Revert also fixes build guile-3. Without it the build fails as:
error: builder for '/nix/store/v3vkr9vaxg278mdi6cv2a0jaqw8mn3xp-guile-3.0.7.drv' failed with exit code 2;
last 10 log lines:
> from alist.c:31:
> /nix/store/2dzi3ls093ffivpp6ykhb3wh33ngyaww-boehm-gc-8.2.0-dev/include/gc/gc.h:1784:11: fatal error: gc_pthread_redirects.h: No such file or directory
> 1784 | # include "gc_pthread_redirects.h"
> | ^~~~~~~~~~~~~~~~~~~~~~~~
Upstream fixed it in master only.
Reason:
- boehmgc_766 (pkgs/top-level/all-packages.nix) is only defined but not
used in Nixpkgs, so dropping it will not affect any package in Nixpkgs.
It was introduced for the asymptote package which has moved on to the
regular boehmgc attribute. There's a slim chance that some user depends
on it, but it would be unrealistic to expect us to maintain the
attribute indefinitely.
Details:
- Delete pkgs/development/libraries/boehm-gc/7.6.6.nix
- Delete pkgs/development/libraries/boehm-gc/riscv.patch
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This round is without the systemd CVE,
as we don't have binaries for that yet.
BTW, I just ignore darwin binaries these days,
as I'd have to wait for weeks for them.
The configure script can't detect whether C11 atomic intrinsics are available
when cross-compiling, so it links to libatomic_ops, which has to be propagated
to all dependencies. To avoid this, assume that the atomic intrinsics are
available.
Fixes#43015 for me and hopefully also similar issues.
== Resource consumption ==
TL;DR: no change for small-memory cases, less CPU for large-memory cases.
I assume almost all of the large memory usage is just the expression
evaluation and managed by the GC, so I used just `nix-env -q...` to test.
Old and new lines for each command follow. I tried to run each several
times, but the values were very stable (<1% difference on re-runs),
so only one line for each command-version pair is provided.
$ time nix-env -f . -qaP --description -A nix >/dev/null
- 0.06user 0.01system 0:00.07elapsed 101%CPU (0avgtext+0avgdata 29036maxresident)k
+ 0.06user 0.01system 0:00.07elapsed 102%CPU (0avgtext+0avgdata 29864maxresident)k
$ time nix-env -f . -qaP --description >/dev/null
- 6.45user 0.36system 0:06.82elapsed 99%CPU (0avgtext+0avgdata 1021024maxresident)k
+ 6.23user 0.33system 0:06.57elapsed 100%CPU (0avgtext+0avgdata 938408maxresident)k
$ time nix-env -f . --show-trace -qa --drv-path --system --meta --xml 2>&1 >/dev/null
- 56.35user 0.96system 0:31.03elapsed 184%CPU (0avgtext+0avgdata 3207708maxresident)k
+ 44.80user 0.91system 0:26.12elapsed 175%CPU (0avgtext+0avgdata 3192696maxresident)k
$ time ./result-nix-large/bin/nix-instantiate --dry-run --eval --strict \
--show-trace ./maintainers/scripts/eval-release.nix > /dev/null
- Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
- Command terminated by signal 6
- 175.18user 2.68system 1:17.42elapsed 229%CPU (0avgtext+0avgdata 8468440maxresident)k
+ 178.48user 2.78system 1:15.11elapsed 241%CPU (0avgtext+0avgdata 8460572maxresident)k
In anticipation of what I outline in #33599, I only simplify exactly those
`doCheck`s which are equal to `hostPlatform != buildPlatform`. I also stick a
comment next to them so I can grep for them later.
