don't use gold linker by default for GCC >= 11.3

[bartoldeman]

Gold is suffering from bitrot, it's better to use ld.bfd by default
as most Linux distributions are doing.

Fixes #2657

[casparvl]

Just my two cents, since I saw some of @boegel 's questions in #2657 :

I think the approach in this PR is good, since it doesn't change existing behaviour. I.e. if I reinstall something for an older toolchain (GCC < 11.3) I'd like to not change the behaviour if we can help it.

I'm curious though @bartoldeman : did you already do some tests to see if using ld.bfd presents any unexpected issues? You could consider compiling a GCCcore-11.2 based stack with use_gold_linker=False and just compile some high-level packages with lots of dependencies. I'm hoping it won't lead to substantial issues, but if it does, it's better we know about it :)

[bartoldeman]

We used the bfd linker very extensively before with the Nix-based stack (mainly with gcc 5.4.0 and gcc 7.3.0), and I don't remember any issues.
On the contrary using the Gold linker has caused us various issues, Julia and a Lustre filesystem issue come to mind.

It doesn't hurt to test but I think we can just take the plunge during develop and if things really turn out badly we can always revert.

rocm-smi, MariaDB, libunwind are others that need to use -fuse-ld=bfd now already.

[bartoldeman]

Well I guess I'll need to take it back for now, @boegelbot does not look happy!
I'll try myself to see why binutils didn't compile this way, looks very odd!
https://gist.github.com/boegelbot/43f6fd8d031b1d69d16ce64fe683d0b8#file-binutils-2-38-gcccore-11-3-0_partial-log-L409

[bartoldeman]

#2712 fixes the issue with binutils.

[casparvl]

Ok, despite the unforeseen binutils issue, I actually agree with you. We should set this as the default for 11.3.0 at the same time that 11.3.0 gets ingested, otherwise we are changing a default again. So spending too much time on testing might not be feasible. And indeed: lot's of others are already using it, so the only issues we might run into are probably EasyBuild-specific (which the binutils issue was in a way), and those should be solveable during develop.

I checked that

eb --from-pr 15311 --include-easyblocks-from-pr 2711,2712 -r

now works, and it does for me on both our clusters. I see it also completed succesfully on generoso. I'll rerun it with --rebuild --upload-test-report so that we have that succes logged for posterity :)

[casparvl]

Test reports are here, here and here. All looking good from my point of view.

[casparvl]

Switching to ld.bfd since ld.gold suffers from bitrot seems like a reasonable approach. Current implementation leaves previous behaviour untouched, which makes the most sense to me.

Some issues are to be expected when we add new EasyConfigs (such as the binutils issue in #2712), but since other projects are already using ld.bfd by default, we can expect most of these to be EasyBuild specific - and thus within our circle of influence to solve. However, since we want to make sure this is the default from the moment GCC-11.3.0 is in EasyBuild, we shouldn't want too long and thus extensive testing is not really an option.

All in all, I say: looks good to me :)

[casparvl]

Test report by @casparvl

Overview of tested easyconfigs (in order)

• SUCCESS GCCcore-10.3.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
tcn1.local.snellius.surf.nl - Linux RHEL 8.4, x86_64, AMD EPYC 7H12 64-Core Processor, Python 3.6.8
See https://gist.github.com/dd3a074240f8cba80ab723a4339551ee for a full test report.

[bartoldeman]

Thanks, yes, indeed the binutils issue looks like a corner case, something that exposed actually exposed a (mostly harmless) bug (GCCcore binutils linking libiberty from system binutils).

[boegel]

lgtm

[boegel]

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS GCCcore-11.2.0.eb
• SUCCESS GCCcore-9.3.0.eb

Build succeeded for 2 out of 2 (2 easyconfigs in total)
node3519.doduo.os - Linux RHEL 8.4, x86_64, AMD EPYC 7552 48-Core Processor (zen2), Python 3.6.8
See https://gist.github.com/6b99fb8fb68a7931925f20d5a7d0880d for a full test report.