Drop support for deprecated GNU Gold linker on non-Darwin Unix

[ADKaster]

Motivation

As of binutils release 2.44 (Feb 2025), the gold linker is officially deprecated, and its sources are no longer included in the default release tarball.

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

In a change to our previous practice, in this release the binutils-2.44.tar tarball does not contain the sources for the gold linker. This is because the gold linker is now deprecated and will eventually be removed unless volunteers step forward and offer to continue development and maintenance.

Proposed solution

It's my understanding that bootstrapping Swift on platforms like Linux defaults to using the GNU Gold linker, rather than lld.

Bootstrap scripts and other install instructions should be updated to mention that the gold linker is no longer maintained upstream, and that the lld linker should be used instead.

Looking around it seems like the swift-driver no longer defaults to gold, and respects the -fuse-ld option more readily on main than in previous releases.

Support for the gold linker should be dropped entirely imo. Attempting to use it could result in an error at the driver level, or it could simply be "not recommended" with issues stemming from its use auto-closed with a "not our problem" message.

Alternatives considered

It's unlikely that the swift team or community have the will to maintain the gold linker themselves.

Additional information

No response

[finagolfin]

Thanks for filing and linking that announcement. The good news is that since the latest 6.0.3 release, the swift-driver always delegates to the C compiler used for linking too, swiftlang/swift-driver@15402470a, and has no more logic to choose a linker itself. Since the clang shipped by Swift picks gold on some platforms, it will still end up using gold there, but that is an upstream LLVM choice.

As for bootstrapping the compiler, unfortunately that is still done with Swift 5.8.1 on the linux CI, and the swift-driver back then chose gold as the linker on some platforms, overriding whatever clang chose. We could of course override that older default in the build presets, which should work fine, because lld has worked well for awhile.

Maybe @etcwilde and @al45tair have more to add, as they made some of those linker changes before.

[ADKaster]

@finagolfin is it really true that using gold on non-darwin is an "upstream llvm choice"? Do you mean upstream llvm as in llvm.org?

As far as I can tell, the generic clang driver code defaults to whatever you pass in as -DCLANG_DEFAULT_LINKER to CMake, or TC.getDefaultLinker(), or just "ld".

https://github.com/llvm/llvm-project/blob/bc646f4b302339717e363efa3e57ec3468d190aa/clang/lib/Driver/ToolChain.cpp#L993

And nobody overrides getDefaultLinker() to be "gold". https://github.com/search?q=repo%3Allvm%2Fllvm-project%20getDefaultLinker&type=code

It seems to me that the only places forcing use of GNU gold would be either swiftlang/llvm-project, or whatever CI scripts are used to create releases and the CMake options they pass.

[etcwilde]

We're forcing the Linux toolchains to default to gold here:

swift/utils/build-presets.ini

Line 929 in 012ac5d

-DCLANG_DEFAULT_LINKER=gold

The older versions of the BFD linker didn't used to work with Swift due to some of the relocations that we emit, which is why we forced it to gold in the first place. Newer BFD versions do work though, but we still support distros that have older BFD's.
It might be time to switch the nightly packages to default to lld though. The issue there is that lld has a very different link algorithm than the normal POSIX linkers where ordering and repetition of linked libraries is important, so the concern is that since lld is less restrictive, we would lose the ability to link with POSIX linkers. That's problematic since some of the systems that at least I have to link for vend specialized custom linkers that are POSIX.

[ADKaster]

That's problematic since some of the systems that at least I have to link for vend specialized custom linkers that are POSIX.

Is this saying that platforms like z/OS or AIX or Solaris or My proprietary unix or whatever are supported, but not tested in a regular CI environment?

That doesn't sound like a "supported" environment to me 😬 . Though maybe I spend too much time on the llvm discord listening to Louis complain about arbitrary OS's broken CI and threatening to remove their support from libcxx.

[etcwilde]

It's "random vendor's arbitrary OS" where they decided to modify the ELF headers themselves for funsies. That part isn't supported, but when their tools do offer a standard POSIX interface and mostly hide those details, we should be able to use those tools.

I do think that maintaining the ability to link with standard linkers as much as possible is desirable. Though I suppose that's a question for the platform steering group. (I've added some of them as reviewers on the PR).

[ADKaster]

Well, that's terrifying. Clearly all these custom OS vendors should just get on the clang train like Wind River did back in 2014 with VxWorks 7. But that's neither here nor there. Personally I'd rather avoid (accidentally or otherwise) relying on deprecated, unmaintained software for a critical step like linking the final executable.

Perhaps there's options you can pass to ld.lld to change its behavior to better match these wonky linkers? Or an option to start experimenting using Rui Ueyama's mold linker for some CI jobs, just to get better linker diversity?

[ADKaster]

@etcwilde There is a pseudo-compatibility option, as it turns out. --warn-backrefs.

This page by @MaskRay details the feature and a few cases that it does not catch: https://lld.llvm.org/ELF/warn_backrefs.html

There's a discussion here from 2020 that talks about whether it's a good idea to enable it by default or not. https://groups.google.com/g/llvm-dev/c/yctdamTluyk

I suspect that enabling this flag will help(?) ensure compatibility with the proprietary vendor linkers you mentioned. Though I'm not sure if --start-group/--end-group behavior is the only behavior you're concerned about.

[MaskRay]

As a maintainer of clang driver and lld, I can confirm that the clang driver's toolchains don't have a preference for gold.
(I, like some people, use LLVM_USE_LINKER=gold to bootstrap when a system doesn't have a faster linker.)

Development on gold slowed considerably around a decade ago, following Cary's retirement.
gold exhibits more issues on non-x86 architectures.
I have extensive experience in this area-in 2018, I contributed to the migration from gold to lld.

I don't know much about Swift, but if you ship clang, it's generally better to invoke clang instead of ld directly on non-Windows platforms.

[MaskRay]

LLD's --warn-backrefs is an excellent tool for ensuring compatibility with GNU linkers. I played a key role in Google's effort to transition from Gold to LLD. Around late 2019, I observed that many executables could no longer link with GNU Gold due to archive ordering problems stemming from missing cc_library dependencies. In 2020, I addressed numerous dependency issues and implemented --warn-backrefs. About a year later, I found that executables could still be linked with Gold—provided I omitted some options it didn’t recognize. This compatibility would not have been achievable without the deployment of --warn-backrefs.