[llvm-dev] Please dogfood LLD

[Rafael Avila de Espindola via llvm-dev]

Rui Ueyama <ruiu at google.com> writes:

> As to the Phoronix benchmark results, I tried linking fftw as an example
> and got a different result. In my test, ld.bfd, ld.gold and ld.lld are all
> on par, and that is reasonable because compile time is the dominant factor
> of building fftw. In the Phoronix tests, LLD was slower than the GNU
> linkers when linking fftw, and I don't know why. The Phoronix tests
> measured the entire build time (as opposed to the time that the linker
> actually consumed), and it seems to me that that is too noisy. (Michael, if
> you are watching this, you probably want to measure only the time spent by
> the linker?)
>
> Regarding the libtool issue, I'm inclined to accept the "GNU" hack. That's
> not really a bad hack. As Ed explained, that is not going to be fixed
> easily as the code generated by libtool is copied to so many projects. If
> we can convince libtool-generated script that we are a GNU compatible
> linker just by adding "GNU" to somewhere in the --version message, it
> sounds like a good deal. We can add a string "LLD is a GNU-compatible
> linker" or "LLD accepts the same command line options as the GNU linker" or
> something like that to the --version string. I think we need this in
> reality.

I used to be against this, but I think I agree now.

My reasoning was that if we did this, it would make it harder to get
libtool changed. The change that libtool really needs is to have sane
defaults: if it doesn't know the linker, there is a good chance it has
gnu like command line options and supports shared libraries.

What changed is that I realized that probably the best way to cleanup a
project that is having problems with libtool is to stop using it. LLVM
did that a long time ago and is not any less portable as a result.

Cheers,
Rafael