significantly reduce size of bootstrap gcc and binutils #36383
Conversation
compressed: 28M -> 20M uncompressed: 201M -> 119M Built using: NixOS@94f3dc4 cc NixOS#36383
|
Success on x86_64-darwin (full log) Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Partial log (click to expand)
|
|
Hmm, I guess if we're recompiling GCC anyway, we should as well do it in a way to avoid this conditional: https://github.com/dtzWill/nixpkgs/blob/94f3dc4fdf0c6b32816d67f422d8220e9954c76e/pkgs/stdenv/linux/make-bootstrap-tools.nix#L145 |
|
Curiously we don't just link libisl statically, but also a few other things like libmpc, libgmp-- currently the references from our Perhaps the conditional should be moved higher in the code? If they're not needed normally they probably aren't needed during bootstrap... :). At least not for gcc, which the position in the script suggests is what they're included for. Also statically linking them during cross as well would be nice, but not sure I'd like to include fixing that in this (unless someone else has a good idea how to do it safely/properly?). |
|
@dezgeg okay to merge as-is (without addressing the conditional inclusion of libisl)? |
|
Seems ok I guess. |
|
Haha, well it can wait for now :). It's not an urgent change for anything I'm doing at the moment, we can revisit when we have stronger motivation / time. Thanks! |
dtzWill
force-pushed
the
feature/bootstrap-debloat
branch
from
94f3dc4
to
444ca37
Compare
|
Resolved conflicts and tweaked tarball generation to be smaller but not require more resources during decompression. Don't have updated numbers for this yet (rebuilding) but in other uses I've found it makes a small difference and doesn't take inordinate amount of time :). |
|
Success on x86_64-linux (full log) Attempted: binutils, gcc7 Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: binutils, gcc7 Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: binutils, gcc7 Partial log (click to expand)
|
|
Alright let's get this in. Thanks folks! |
dtzWill
force-pushed
the
feature/bootstrap-debloat
branch
from
444ca37
to
db20e47
Compare
|
Tagged this before updating, JIC: https://github.com/dtzWill/nixpkgs/releases/tag/pr36383-1 |
Apparently this option trades compression time for size, and explicitly does so without increasing resources needed in decomp. Doesn't make tarball creation unbearable, so add it to options!
dtzWill
force-pushed
the
feature/bootstrap-debloat
branch
from
db20e47
to
4c50c2b
Compare
|
@dtzWill What's the status of this PR? |
|
Not sure, sorry! It's on my TODO to get back to you about this
but just wanted to make sure silence wasn't misunderstood :).
…On Thu, 31 Jan 2019 11:21:17 -0800, Matthew Bauer ***@***.***> wrote:
@dtzWill What's the status of this PR?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#36383 (comment) part: text/html
|
|
Are there any updates on this pull request, please? |
|
@dtzWill nobody asked, so let me try: why? If this is only used for bootrstrap, why care then? If this is for cases, when some new platform has to be boostrapped on an embedded device, then we can use cross tools on a powerful machine for this (and copy closure thereafter), right? |
Thank you, this is a good question that slightly caught me off-guard. Which is good 👍. Here's a few reasons I came up with:
That's what I have now, anyone care to add or comment? (yes please) |
|
This is breaking ofBorg evals, as in #72660 trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`
trace: lib.zip is deprecated, use lib.zipAttrsWith instead
error: while evaluating the attribute 'constituents' of the derivation 'nixpkgs-20.03pre999999.ofborg' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/build-support/trivial-builders.nix:7:14:
while evaluating the attribute 'buildCommand' of the derivation 'stdenv-bootstrap-tools' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/stdenv/linux/make-bootstrap-tools.nix:197:5:
while evaluating the attribute 'buildCommand' of the derivation 'stdenv-bootstrap-tools' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/stdenv/linux/make-bootstrap-tools.nix:48:7:
while evaluating anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/lib/customisation.nix:77:32, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/stdenv/linux/make-bootstrap-tools.nix:36:13:
while evaluating 'makeOverridable' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/lib/customisation.nix:67:24, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/lib/customisation.nix:77:41:
anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/development/compilers/gcc/8/default.nix:1:1 called with unexpected argument 'enableLTO', at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/lib/customisation.nix:69:16 |
|
fix in #72713 |
Removals:
stdenv bootstrap will build more feature-complete versions
of these anyway, and they require significant space.
On x86_64-musl bootstrap tarball, here's the difference:
Which brings them back to around what the sizes were
when I last generated the bootstrap tarball
(using gcc6, some time early 2018)
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)I've tested the resulting bootstrap tools are sufficient for bootstrapping
a new stdenv, after which they shouldn't have any impact anyway :).