Why does GHC take so long to link?

Question

>cabal update
>cabal install cabal-install
.......
[43 of 44] Compiling Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tm         


        

Answer 1

This should be a comment, but I cannot format code like this in comments:

I managed to use gold as the linker used by GHC, working around standard ghc-with-gold errors like /usr/bin/ld.gold: --hash-size=31: unknown option, by installing binutils-gold (as suggested in Michael Snoyman's answer) and then replacing the symlink /usr/bin/ld by the following script (made executable with chmod +x):

#!/usr/bin/env python2

import sys
import os
import subprocess


tofilter = [
    "--hash-size",
    "--reduce-memory-overheads",
]

filtered = [ a for a in sys.argv if not any(a.startswith(p) for p in tofilter) ]
filtered[0] = "/usr/bin/ld.gold"

subprocess.check_call(subprocess.list2cmdline(filtered))

Note that trying to set the linker with ghc -pgml /usr/bin/ld.gold or ghc -pgml /usr/bin/ld.whateverElse is not sufficient because the argument to -pgml needs to be a replacement for GCC, not LD. GHC calls GCC, which calls /usr/bin/ld; this is why the above script works.

Answer 2

Very likely it's the linker itself. The standard ld from binutils is known to be slow. If you want to speed things up (and live a bit on the edge), try installing the Gold linker. On Ubuntu (and I assume Debian), that would be:

sudo apt-get install binutils-gold

I've been using it on my home system for a while now, no issues yet.

Answer 3

GHC will by default create a standalone library/executable (static linking).

Dynamic linking has been supported for a while now, so you could try turning it on. With less work to do, the linker is likely to be much faster. On the other hand, you'll need to make sure that at execution time the dynamic libraries you rely on are available (LD_LIBRARY_PATH variable on Linux).