binutils: unbreak w/musl via upstream commits

[dtzWill]

Motivation for this change

53e1db9#commitcomment-32020416

Try building 'busybox-sandbox-shell' without these fixes,
observe crash :(.

Try building 'busybox-sandbox-shell' with these fixes,
observe no crash! \o/

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[dtzWill]

cc @vcunat @NeQuissimus (mentioning the commit didn't seem to 'ping' that discussion? dunno)

[vcunat]

Yes, GitHub doesn't backlink mentions of commits.

[vcunat]

I just hope we won't need many iterations to make binutils usable. Otherwise I can't really see why switching the default version. Have you considered taking the whole 2.31 maintenance branch they have in git?

[NeQuissimus]

@GrahamcOfBorg build busybox-sandbox-shell

[dtzWill]

Yes, I was trying to submit what I thought would get accepted/fixed first... to unbreak my things xD. (and with reproducible and simple example of breakage/fixing) One would hope with that many changes/fixes they'll cut a new release soon? Wishful thinking, of course, gah. If it wasn't so rebuild-costly I'd in fact suggest we follow it closely, after vetting them and such. Hmm, anyone know /offhand/ how other distributions handle this? O:)

…

On Tue, 22 Jan 2019 19:27:53 +0000 (UTC), Vladimír Čunát ***@***.***> wrote: I just hope we won't need many iterations to make binutils usable. Otherwise I can't really see why switching _the default_ version. Have you considered taking the whole 2.31 maintenance branch [they have in git](https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_31-branch)? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #54464 (comment) part: text/html

[NeQuissimus]

Ubuntu bundles a ton of patches: https://packages.ubuntu.com/cosmic/all/binutils-source/filelist

[vcunat]

I believe we can easily afford a stdenv rebuild every month. Human time is more of a problem for me here – just deciding whether patches are mutually independent (and I don't mean failures of applying them) and which of them matter for us.

[dtzWill]

Okay to merge as-is to get this fixed (things are broken currently!), and we can "upgrade" binutils further as a separate PR/issue? I'd say RFC but that seems a bit heavy for this sort of discussion :).

[Mic92]

Is it possible to use fetchurl for any of these or did you patch them locally?

[dtzWill]

Wasn't sure fetchpatch would work re:bootstrap, can probably grab via fetchurlBoot but would need some fetchpatch (filterdiff) alternative to drop the changelog portions of the commits (I kept the commits separate in this PR to help make that clear, esp looking back later on).

Anyway maybe we can, but not sure how reasonable it'd be. Maybe there's a nice way to do it, in which case I agree that's be preferable.

[vcunat]

I think I tried hard to find a way when patching glibc with upstream commits, some time ago, and I failed. I ended up putting large gzipped diffs into nixpkgs.

[Mic92]

ok then.