</varlistentry>
<varlistentry>
+ <term>Do I have to recompile all my code if I upgrade
+ GHC?</term>
+ <listitem>
+ <para>Yes. There are two reasons for this:</para>
+ <itemizedlist>
+ <listitem>
+ <para>GHC does a lot of cross-module optimisation, so
+ compiled code will include parts of the libraries it was
+ compiled against (including the Prelude), so will be
+ deeply tied to the actual version of those libraries it
+ was compiled against. When you upgrade GHC, the libraries
+ may change; even if the external interface of the
+ libraries doesn't change, sometimes internal details may
+ change because GHC optimised the code in the library
+ differently.</para>
+ </listitem>
+ <listitem>
+ <para>We sometimes change the ABI (application binary
+ interface) between versions of GHC. Code compiled with
+ one version of GHC is not necessarily compatible with code
+ compiled by a different version, even if you arrange to
+ keep the same libraries.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>Why doesn't GHC use shared libraries?</term>
<listitem>
<para>The subject of shared libraries has come up several
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>Why does linking take so long?</term>
+ <listitem>
+ <para>Linking a small program should take no more than a few
+ seconds. Larger programs can take longer, but even linking
+ GHC itself only takes 3-4 seconds on our development
+ machines.</para>
+
+ <para>Long link times have been attributed to using Sun's
+ linker on Solaris, as compared to GNU <command>ld</command>
+ which appears to be much faster. So if you're on a Sun box,
+ try switching to GNU <command>ld</command>. <ulink
+ url="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-November/004477.html">This
+ article</ulink> from the mailing list has more
+ information.</para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</chapter>