LLVM Is Developing A New ELF Linker

[phoronix]

Phoronix: LLVM Is Developing A New ELF Linker

The LLVM project has announced they've developed a new ELF linker by rewriting the ELF support within LLVM's LLD...

http://www.phoronix.com/scan.php?page=news_item&px=LLVM-New-ELF-Linker

[elmerovingio]

The LLVM ecosystem is growing, indeed.
IIRC, there's only an assembler missing in order for LLVM to provide a full stack for compiler designers (mainly Clang)

[discordian]

Its a godsend for anyone interested in Compilers. For production and embedded you still rely on binutils, and I doubt the linker will get full compatibility with ld for some years.
ld and its scripts are obese with hidden functionality and special conditions.

An a second thought a clean new script desing would probably be a more worthwhile target

[PuckPoltergeist]

Gold still isn't fully compatible to bfd, and the llvm-developers claim to reach this goai?

[fliX]

IIRC, there's only an assembler missing in order for LLVM to provide a full stack for compiler designers (mainly Clang)

Clang has its own built-in assembler. Just compile with the "-xassembler option" (or create a symlink from clang, named as) to use it as a stand-alone (and command-line comaptible) GNU as replacement.

Gold still isn't fully compatible to bfd, and the llvm-developers claim to reach this goai?

No, they don't. Instead they say "lld is not at feature parity with gold yet"

[Pacific Rim]

Gold still isn't fully compatible to bfd,

Do you have an example? Sometimes the difference is intentionally. For example, -Y on gold acts differently than bfd, on purpose. The man page of ld.bfd says -Y is meant for compatibility with Solaris, yet acts differently than solaris. Gold matches the Solaris implementation as advertised. Technical that means gold is "not compatible" with ld.bfd, and it never will be by that measure. Your quote implies ld.bfd does everything correctly and thus is the standard from which everything else should be measured, but I might debate that.

[staalmannen]

So what else is needed to make LLVM/Clang completely binutils-independent? if as (clang) and ld (lld) are there. If I remember correctly there are already ranlib and objcopy alternatives in LLVM?

[Ansla]

Do you have an example?

I have some:
-warn-once
--hash-size
--default-symver
and other problems tracked here, including stuff that builds but doesn't work properly.

[Pacific Rim]

I have some:
-warn-once
--hash-size
--default-symver
and other problems tracked here, including stuff that builds but doesn't work properly.

Okay, thanks but lets look at these:

--warn-once: This looks current, but it is a warning flag. There are plenty of gcc warning flags that clang still doesn't recognize. The point is, this is not a performance thing, something that affects it's ability to link. Failure to be compatible with ld.bfd is true, but weak
--hash-size: this seems like the original issue is that ghc configure didn't test for supported linker options. I see reports going back 5 years. It looks like hash-size is implementation specific, e.g. performance tuning. I don't know fair ld-specific performance tuning against gold
--default-symver: this might be legitimate: https://sourceware.org/bugzilla/show_bug.cgi?id=15910

I would be interested to know the true impacts of the last one (e.g. why does software "require" it and why can't standard symbol maps be used instead).