[project @ 2003-12-16 16:18:08 by simonpj]

[ghc-hetmet.git] / ghc / docs / users_guide / faq.sgml

diff --git a/ghc/docs/users_guide/faq.sgml b/ghc/docs/users_guide/faq.sgml
index 8055d15..f9b27ab 100644 (file)
--- a/ghc/docs/users_guide/faq.sgml
+++ b/ghc/docs/users_guide/faq.sgml
@@ -45,6 +45,34 @@
     </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
@@ -277,6 +305,41 @@ details.</para>
       </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>
+
+    <varlistentry> 
+
+      <term>If I explicitely set the buffering on a Handle to
+      "NoBuffering" I'm not able to > enter EOF by typing
+      "Ctrl-D".</term>
+
+      <listitem>
+       <para>This is a consequence of Unixy terminal semantics.  Unix
+        does line buffering on terminals in the kernel as part of the
+        terminal processing, unless you turn it off.  However, the
+        Ctrl-D processing is also part of the terminal processing
+        which gets turned off when the kernel line buffering is
+        disabled.  So GHC tries its best to get NoBuffering semantics
+        by turning off the kernel line buffering, but as a result you
+        lose Ctrl-D.  C'est la vie.</para>
+      </listitem>
+    </varlistentry>
   </variablelist>
 </chapter>