gecko: building with clang should use lld as the linker

[glasserc]

Apparently it's much faster than gold: https://groups.google.com/d/msg/mozilla.dev.platform/iwQ9R6NS3yA/nZwrwtKoBAAJ. However, since gcc is still supported, we should perhaps only use lld when using clang.

[glasserc]

I was able to build by adding llvmPackages_7.lld to the buildInputs and ac_add_options --enable-linker=lld to the genMozConfig script, but the compiled firefox wasn't linked properly to libc++ and libc++abi. I think adding export LDFLAGS="-Wl,-L${llvmPackages_7.libcxx}/lib -Wl,-L${llvmPackages_7.libcxxabi}/lib" to genMozConfig is enough (trying it now), but I'm not sure if there's a cleaner way. Also, is ! stdenv.cc.isGNU the best way to check if we're clang?

[glasserc]

Hmm, it seems like the linker problems (which, for posterity, are: error while loading shared libraries: libc++abi.so.1: cannot open shared object file: No such file or directory) are probably not related to the change in linker. So maybe adding lld to buildInputs and --enable-linker=lld is enough. EDIT: Actually, I'm not sure -- I forgot to comment out adding lld to buildInputs. Trying again...

[glasserc]

This seems more complicated than I expected at first. It seems that lld has some behavior about linking that I find surprising: libraries that it builds do not actually resolve links to other shared libraries. I'm not 100% sure of my vocabulary here but here's an example:

> cat blah.cpp
#include <stdio.h>

int blah() {
  printf("Hello world\n");
  return 0;
}
> clang++ -shared -o libblah.so blah.cpp -fuse-ld=lld
> ldd libblah.so
	linux-vdso.so.1 (0x00007fff7fd4b000)
	libc++abi.so.1 => not found
	libc++.so.1 => not found
	libm.so.6 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libm.so.6 (0x00007f7dedca5000)
	libgcc_s.so.1 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libgcc_s.so.1 (0x00007f7deda8f000)
	libc.so.6 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libc.so.6 (0x00007f7ded8d9000)
	/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f7dede42000)

Here we see that libc++ and libc++abi aren't actually linked. Why? We can also try explicitly linking another shared library, in this case libdbus-1:

> clang++ -shared -o libblah.so blah.cpp -L/nix/store/5l5yvz2rz35hlgsh80vm8vi1wr3gj8d0-dbus-1.12.12-lib/lib -ldbus-1 -fuse-ld=lld
> ldd libblah.so
	linux-vdso.so.1 (0x00007fffc5966000)
	libdbus-1.so.3 => not found
	libc++abi.so.1 => not found
	libc++.so.1 => not found
	libm.so.6 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libm.so.6 (0x00007f86959e3000)
	libgcc_s.so.1 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libgcc_s.so.1 (0x00007f86957cd000)
	libc.so.6 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libc.so.6 (0x00007f8695617000)
	/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f8695b80000)

Same thing. The -L is necessary for it to find the library, but for some reason it isn't linked. I was able to "force" it for libc++ and libc++abi by using -Wl,-rpath=${llvmPackages_7.libcxx}/lib, which are the only two that aren't linked in the firefox binary, but libxul.so has a dozen other unlinked libraries (GTK, DBUS, Pango, Freetype, X11, you name it) so the browser still fails to run. I'm not sure what's going on, if this is expected behavior or what. However, I noticed that when I changed the linker options and did the rebuild, I got the following results:

• Gold run 1: 51:40.09
• Gold run 2: 52:12.41
• LLD (with single -rpath c++abi): 58:30.32
• LLD (with two -rpath-link): 54:37.92

From this I can see that LLD is not buying me any improvements in terms of compile time. For this reason I'm going to drop this for now.