Nixpkgs: binutils is huge

[vcunat]

Commit de28bd4832 grew binutils.out from 26 to 206 MiB, and as a result stdenv closure grew considerably. The commit (and issue) is several months old, so both master and 18.03 are affected.

@Ericson2314: that was an accident and not a known trade-off, right?

[vcunat]

My first guess is unintended static linking.

[7c6f434c]

My first guess is inclusion of some code for a range of target architectures by default.

[Ericson2314]

@7c6f434c is probably right. Removing --enable-targets=all from binutils (but leaving it in the libaries because they shouldn't be target-specific) should fix that. It ended up being not the most useful anyways because the assembler is written differently and still target-specific, so the multi-target binutils cannot be reused for cross. We kept it on a whim as a convenience for anyone using objdump and friends on other binary formats, but didn't realize the space blow up was that bad.

[samueldr]

5 days ago, b2db3f8

Fixes #44936

This issue is still open; can it be closed?

[Ericson2314]

Oh that fixes a different issue. This one still needs to be fixed. I'm away from my computer but hopefully the instructions I left before make sense.

[vcunat]

@Ericson2314: why did you switch the build to static in f8741c38cd54?

[vcunat]

OK, both guessed causes play a role. Using all dynamic (from the separate libs), I get on ~110 MiB total with all targets. ~50 MiB of ldscripts is conspicuous in there. ~27 MiB from the two libraries could be shared with other packages, with some small adjustment of stdenv bootstrap, but such packages are few, so that's probably not a significant advantage.

I suppose we don't need all the targets in the default version.

[Ericson2314]

@vcunat Sorry, that is my mistake. I didn't binutils to install any libraries when I made the separate libopcodes derivation. But that's what --disable-install-libbfd is should do. I have no idea why I also switched to static linking.

[vcunat]

The line "--disable-shared" "--enable-static" does it ;-)

[Ericson2314]

You mean without those flags, those libraries still are installed despite --disable-install-libbfd?

[vcunat]

Not installed; the installed libraries are relatively small and would be easy to delete anyway. What increases the size by a few megabytes is presumably copying the statically linked code in several executables. EDIT: so unless you see a reason to keep static, my plan (and testing) was to switch to dynamic by default.

[Ericson2314]

Yes, absolutely agree lets make it dynamic again. I'll make a PR.

[vcunat]

Probably wait, I have it already, tested to some extent etc. just not published, because there's been so much going on now.

[Ericson2314]

OK. I was hoping to take something off your plate :) but if not making one is easier for you, then I won't. Only gotcha is I think GDB needs the same change.

[vcunat]

You can, but start on what I've done already ^^

[Ekleog]

Should be partially solved by https://github.com/NixOS/nixpkgs/pull/46056, despite the fact it's not back to 26M but to ~70M… should we keep this open to track the remaining regression?

[vcunat]

Hmm, we shouldn't have binutils in usual runtime closures, so I guess it will now be small enough to close.