More seriously, being a package maintainer myself I know that the goal is to serve the users and create packages that users expect. So, the best way to get package maintainers to include LLD is to get users to expect it.

I started working on a proof of concept operating system, and according to the OS Dev Wiki, the first thing you have to do to get started is to build a cross compiler. This is because by default the C compiler and linker are compiled only for the current system. When I started making the OS in Zig, however, I did not have to build a special cross compilation version of Zig, because it supports cross compilation out of the box for every target and OS. For example, unlike in C, compiler_rt/libgcc are shipped with the compiler in source form and built lazily for the desired target.

So not having to build or obtain a special gcc was nice, however, I did have to build a cross compiled GNU binutils so that I could use an ARM linker on an x86_64 host. If I can depend on LDD, then I can support cross compiling for every target with no other dependencies needed.

Using the system linker means throwing away those benefits, in name of lowest common denominator.

On the majority of other OSes, each programming language used to have its own linker.

This is why although I dislike some of Go's decisions, I am quite supportive of its uptake.

- Bostraped language, with very few dependencies on C

- Runtime library makes direct use of syscalls, instead of taking the easy way and depend on libc

- It has its own linker

- Despite the GC hate and the whole discussion what is "systems programming", people are indeed slowly using for such purposes

I can tell you that even when I am using clang and LLVM to target another system, except for minor variations where I am targeting the same operating system and the same vendor with the same target executable format across only different CPU vendors (i.e.: Apple), I still have to end up with different full cross-compiler tool chains, often based on entirely different forks of the code base for LLVM.

Even if it were possible, and it is not clear to me that it is or that it would even be desirable (as you still need a set of highly platform-specific libraries and header files, even for weirdly quirked-up core libraries like the moral equivalents of libgcc that are needed for every subplatform, due to symbol visibility), in practice we just aren't there yet, as there are too many extremely subtle platform differences... the only way we could even get close to this dream would really be to have a mindset that a platform is a massive file of configuration warts that you pass to the compiler, as opposed to some trivial flags like -mllvm -arm-reserve-r9.

Not all system linkers have this problem. For example, Solaris ld(1) is perfectly capable of cross-linking any valid ELF file.

Performance.

>> (usually more than 2x faster than GNU gold).

I switched from bfd to gold to realize a ~6x performance gain on a project (~1 minute linking -> ~10 seconds linking, times 10-20 subprojects, times a few build configurations - really adds up!) I'll keep in mind that I now also have the option to switch to LLD for another 2x (12x total?)

As an example, many of the C++'s drawbacks regarding build systems was because Bjarne wanted that the generated object files and libraries could be transparently linked by a linker that only understood C.

And shouldn't the name be llld?

Seriously though. I guess the majority of major FOSS software out there have a goal of retaining GNU compatibility, so I'd be surprised if this turned out to be an issue.