Tracking issue for -Z linker-flavor

[japaric]

Added in #40018

This flag changes how rustc invokes the linker. This is required to use LLD as a linker with
targets where e.g. gcc is the default linker.

@alexcrichton what would be the stabilization path here? Do we need an RFC? If yes, what should it
specify?

[alexcrichton]

I think I'd personally be ok avoiding an RFC on this so long as we've got a solid design. One step I'd preferrably like to see before stabilization is some documentation which rationalizes -C linker and a hypothetical -C linker-flavor argument as well (aka do they affect each other in terms of defaults?).

For example we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some "simple inference" based on the linker's file name, although we'd likely still want to one day stabilize -Z linker-flavor

[japaric]

we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some "simple inference" based on the linker's file name

This sound like a good step forwards. I can look into it, probably by next week.

Two questions though: when you do -C linker=lld do you always get the LLD shipped with the Rust toolchain, or is the LLD in the unmodified user PATH, if any, the preferred LLD? In either case will we ever want some special -C linker argument to express preference for one or the other: for example -C linker=rustc.lld will always give you the LLD in the sysroot.

The other question is: are there any stability guarantees around -C linker=lld (i.e. use the LLD in the sysroot)? Will we ever remove the LLD binary in the sysroot in favor of having rustc call LLD as a library?

[alexcrichton]

Heh all excellent questions! I'm detecting a trend as well with the topic :)

Honestly I'm not entirely sure what to do about the stability of LLD. Today, and historically for a very long time, we have prepended the sysroot bin path to PATH when invoking the linker unconditionally. This means:

• If we ship LLD in that sysroot location then it will always be preferred.
• The only way to switch to a system LLD would be to use -C linker=/path/to/lld
• Using LLD would be "insta stable", as you've realized, because -C linker=lld works

The reason we unconditionally prepend PATH is related to MinGW and the rust-mingw component where we ship a gcc.exe linker for Windows users so they otherwise wouldn't need to install a large development environment to get up and running with Rust. This also has cons, however, in that it means we accidentally prefer our own gcc.exe even when C code may have been compiled with an external gcc.exe, causing link errors from time to time.

Now we don't have to put LLD in the same location, nor do we need to give LLD similar treatment. At the time of implementing LLD support it was basically the easiest option.

So another question entirely about stabilizing LLD is whether its command line options are stable. For example does LLD remove options arbitrarily? Tweak and/or making breaking changes to its interface? Today we'd inherit such breakage and expose rustc users to that possibly.

As to whether we'll ever invoke LLD as a library, I sort of doubt it. I would personally prefer to do that because it's cheaper than spawning a process, but LLD is internally architected for abort-on-error from what I could tell so we wouldn't get a chance to gracefully handle failures in rustc. As a result it seems like a safe bet that we'll be using it as a binary for the forseeable future.

---

Where that leaves us, I'm not sure. I think using a binary file name like rustc-lld makes sense in that it'll make it much easier to use LLD externally installed on the system. I feel like we're going to get the most bang for our buck by just shipping LLD and praying, but such a strategy is almost guaranteed to cause a huge amount of pain down the road when something breaks.

I guess this is sort of the same bucket of all LLVM tooling. We'd love to expose it but run a high risk of causing a large amount of pain as soon as anything has a backwards-incompatible change (which everything else in LLVM seems to do fairly often). Maybe LLD isn't in this class of tools though? I think it's supposed to be a drop-in replacement for existing tools with stable interfaces, so as long as we use those stable interfaces (aka ld-like options) we may be in the clear

[japaric]

So another question entirely about stabilizing LLD is whether its command line options are stable.

If we go with rustc-lld equals "always the LLD in rustc sysroot" then we can provide more
stability for rustc-lld than what we can provide for external linkers.

If the CLI of LLD changes in a future LLVM release then we can fix that transparently by having a
special linker flavor for rustc-lld. This special (always used when linker = rustc-lld) and
internal (not exposed via -Z linker-flavor) RustcLld linker flavor will use the right CLI args
for the LLD version we ship.

We can't provide this kind of CLI stability for external linkers because the user can use any
version of e.g. GNU LD. Unless we make rustc probe at runtime the version of the linker (ld -v) to adjust how it invokes the linker but that sounds like a lot more work than what's required
for stable rustc-lld.

TL;DR I don't see much hazard in stabilizing -C linker=rustc-lld; we control and thus know the LLD
version that's shipped with rustc so we can guarantee that LLD will always be invoked with the
right CLI.

---

we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some
"simple inference" based on the linker's file name

This sound like a good step forwards. I can look into it, probably by next week.

I have a WIP PR for this: #50359

I also think it makes sense to rename rustc's LLD to rustc-lld to avoid shadowing the lld in the
user's PATH.

[alexcrichton]

Heh I'm not sure I 100% agree with the rationale but I definitely agree with the conclusion :)

The main part is that users can still specify custom arguments via -C link-arg, and I'm not sure how we'd solve that with a shim over LLD. Regardless I like renaming to rustc-lld to avoid clashing with PATH and allowing usage of LLD in PATH anyway.

[davidthomaswood]

From looking at cambridgeconsultants/rust-beagleboardx15-demo#1, this flag was stabilized in 9536d04, and is now -C linker-flavor

[jonas-schievink]

Uh okay, closing I guess ¯\_(ツ)_/¯