Revert binutils installation

[RalfJung]

This reverts #161243 as that broke the Miri build again.

Can we maybe build the GCC backend on a different builder where it cannot affect anything else? Or in a separate docker container, or so? Apparently, the GCC build system is so arcane that it is nearly impossible to build GCC without side-effects on the rest of the system.

Cc @Kobzol @GuillaumeGomez

[rustbot]

r? @marcoieni

rustbot has assigned @marcoieni.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: infra-ci
• infra-ci expanded to Kobzol, Mark-Simulacrum, jieyouxu, marcoieni, ubiratansoares
• Random selection from Mark-Simulacrum, jieyouxu, marcoieni, ubiratansoares

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 2ad19ce

[Kobzol]

I'd suggest bumping

rust/src/ci/run.sh

Line 243 in 93a81b4

export SCCACHE_C_CUSTOM_CACHE_BUSTER=1

, just to be on the safe side. We should also bump the CI timeout to at least 7h, I'll do that separately.

[Kobzol]

Actually, nevermind about the timeout bump. GHA doesn't allow jobs running for longer than 6h.

[RalfJung]

I'd suggest bumping

Will do.

I have two try builds going on to maybe learn a bit more about the issue in case that lets us do a full revert. But if we don't have any idea by tomorrow morning, a revert is probably the best option. I looked at that libtikv_jemalloc_sys-d80fed9554ea7cfd.rlib file and it seems indeed corrupted, so this should affect not just Miri but everyone building rustc drivers such as clippy or rustdoc against the rustc-dev component that we ship. aarch64-linux just doesn't have that many users which is likely why nobody else notices.

[antoyo]

Just to make sure #161243 is really the cause here: did you run your out-of-tree miri build against the current PR (this revert)?

[RalfJung]

Just to make sure #161243 is really the cause here: did you run your out-of-tree miri build against the current PR (this revert)?

Not yet. It's the exact same symptoms as last time. But sure, we can double-check.
@bors try jobs=dist-aarch64-linux

[rust-bors]

⌛ Trying commit b9e31fc with merge 0d71559…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/32572474480

[RalfJung]

Hm, maybe you were right to be suspicious... it looks like c656540 may actually work fine, and that includes #161243! Did #161260 cause the exact same symptoms as the previous attempt at bumping binutils?!?

[RalfJung]

Yeah, it wasn't the GCC PR this time. So sorry for this! I should have checked earlier rather than just going based off of "the symptoms are exactly the same".

[GuillaumeGomez]

It's a big relief. :')

And no problem, thanks for double-checking. :)