[utils] Replace gold with lld as the default linker on Linux

[ADKaster]

GNU Gold is deprecated[0] and will not be updated by upstream binutils. This begins with binutils 2.44, released in February 2025.

[0] https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html

Resolves #79163

cc @etcwilde

[etcwilde]

For visibility, I'm mostly fine with using lld. My main concern though is that lld does not use a normal link algorithm and I'm concerned about losing the ability to use POSIX linkers if we aren't verifying that they work since the link algorithm is generally more sensitive to changes in link flag repetition and ordering.

[compnerd]

This is something that we discussed with the changes to Swift Build as well. We should be using the default linker on the platform (ld), and letting the OS decide if it wants to default to BFD, LLD, or gold. This definitely is a change that we would need to worry about from the CI perspective (CC: @shahmishal) as it introduces a new dependency for the build.

[ADKaster]

In the cases where the default system linker is BFD, and that version of BFD trips over the swift compiler/runtime's use of protected symbols, what to do then?

It seems from my limited view of this issue that the decision a few months ago was was to use gold to cover that gap, but gold is now unmaintained and deprecated.

Is a more comprehensive CMake configure-time check (aka 'does the system linker handle this known protected symbols test case properly') in order here?

[compnerd]

Yeah, a more comprehensive fix would be better:

1. If building for a UNIX system (if(UNIX)), we check the linker.
2. If it is BFD and is new enough, we continue.
3. If it is BFD and is too old, we error out.
4. If it is LLD, we just continue.
5. If the selected linker is gold, we emit a deprecation warning.

[etcwilde]

We build and install lld as part of the toolchain build so I don't think it actually introduces anything additional to what we already have (from build-script's perspective, which is what this is changing anyway), we just aren't using it by default (which is also a little weird, IMO).

We definitely can't just remove setting this preset to use gold or we will see failures on the Ubuntu 22.04 PR tests. I have #77635 that I should probably just finish. Then the nightlies can use that preset while other testing can validate that one of the POSIX linkers still works. Amazon Linux 2023 somewhat ironically has a new enough BFD that it would totally work for this purpose, but no gold linker.

[al45tair]

I believe the current plan is to generally avoid having Swift specify which linker to use and let Clang make that decision instead. Ubuntu 22.04 is supported (by Ubuntu) until April 2027, and I assume we're likely to continue to support Swift on that platform until then, so we will need some kind of workaround until at least that date.

The question then is what we should do. I think we can statically detect the platforms where this is a problem at (Swift compiler) build time. At that point, we have a couple of options:

1. Put in the installation instructions for those platforms an instruction to install a newer linker, in a place where Clang will pick it up, or
2. On those platforms only, add -fuse-ld=lld (since we're shipping lld, this doesn't requiire any extra things installed on the part of the user).

Perhaps the thing to do here is to go through our currently supported platforms and look to see which ones use the older BFD linker as the default, and then look to see what their end-of-life date(s) are. If the EOL dates aren't too far away, (1) seems reasonable, particularly if newer versions of those platforms with non-broken linkers are already available. If the EOL dates are further off, maybe (2) would be a better choice.

[finagolfin]

Just one note, as Evan says, the default is lld, so the better way to make this switch is to delete these 9 lines.

[etcwilde]

I know we install it lld by default, but the clang-linker itself will still use BFD, which I believe will fail PR testing due to the relocation bug.

[finagolfin]

Sigh, setting this linker is a maze of config options and overrides. 😿

[finagolfin]

Btw, I now see that @gottesmm just added a --use-linker flag last month in #79329. Whatever we decide to do here, we should switch these presets over to that new flag instead of these raw cmake overrides.

[etcwilde]

Oh yeah. I can go ahead and update my lld PR to use that flag and incorporate that change there.

[etcwilde]

It is possible to set different presets on the various nightly packages. If we have separate presets for gold vs lld vs default-linker and a list of which versions of which distros have support for each, I can go in tell the package builder to select the appropriate preset with the appropriate linker default.