Fedora (riscv64): binutils 2.42 (instead of 2.41 for the rest)

We are slowly preparing for Fedora/RISCV (i.e. riscv64) mass rebuild with GCC 14. We already have the initial GCC 14 builds done. For quite some time (multiple Fedora releases) we use the latest available binutils (N) version instead of what’s available general Fedora (N - 1, i.e. one version behind the latest available). After looking at the git log between 2.41 and 2.42 I plan to continue this. @nickc I did a great job already backporting ULEB fix and a workaround from binutils 2.42 to 2.41 in Fedora. Otherwise there are also broken encodings for some T-HEAD extensions (fixed in 2.42), new extensions (e.g. part of RVA23 profile). RVA23 is an important milestone (not yet ratified) as it seems non-ISA specifications for server platform are currently pointing to it as a requirement. RVA24 is expected to become the next major profile.

Technically we should be fine start to start mass rebuild with 2.41 and land 2.42 sometime later after Fedora 40 gets branched. @nickc is usually fast to land a new binutils version after branching.

cc @codonell @rjones

1 Like

Is it possible to enable ld.gold? It is required by ghc unless we patch it.

No. It’s not required by GHC (it builds fine with ld.bfd).

To my knowledge no one is actively working on ld.gold support. To my understanding ld.gold is no longer in active development in general. See:

PLCT Lab had it on their roadmap for 2022, but I haven’t seen any activity.

The only linkers that support riscv64 (and are on active development) are ld.bfd, LLD, and mold.

FYI - I am working on rebasing rawhide binutils to 2.42, but I am going to wait until after the F40 branch before committing my changes. Assuming that nothing goes drastically wrong with my scratch builds however the updated binutils should be available shortly after the branch completes.


A scratch build of the 2.42 binutils for RISCV64 can be found here:
build (rawhide, binutils-2.42-1.fc40.src.rpm) | Task Info | Fedora RISC-V

1 Like

Amazing work as usual. Fedora 40 branching is almost here. I assume it’s worth waiting a bit and see it land in dist-git. Just to make sure that NVR has exact same content between two Koji instances.

@nickc I think one of the test failed or logs are missing on FEDORA-2024-86f122ac31 — unspecified update for binutils — Fedora Updates System Is it possible to re-spin the tests?

The only test that appears to have failed is the static analysis test. This is non-voting, so it should not stop the build reaching the buildroot.

The static analysis test had two failures. The ‘unicode’ test is labelled as BAD, but this is a false negative. The unicode test is detecting suspicious unicode characters in the assembler testsuite, but these characters are there expressly to test the assembler’s ability to detect and report suspicious unicode characters…

The annocheck test is failing for the i686 version of addr2line (and probably other i686 binutils executables). This is a known issue with annocheck. Since it was decided a short while ago to build i686 binaries without control flow security enhancements (ie gcc’s --cf-protection option) annocheck has started flagging them up as FAILing to use control flow proctection. This issue took a few iterations of annocheck to fix, but as of version 12.39 annocheck should be properly ignoring this test for i686 binaries.

Oh, and just answer your actual question, I do not think that there is a way to re-spin the tests without creating a new build. But the logs are there. If you click on the “results.json” link near the bottom of the page for the failing test you will find the full output. It is not easy to read, but it is there.