Update a few points about shared libs in other sections
authorDuncan Coutts <duncan@well-typed.com>
Sat, 4 Jul 2009 21:22:12 +0000 (21:22 +0000)
committerDuncan Coutts <duncan@well-typed.com>
Sat, 4 Jul 2009 21:22:12 +0000 (21:22 +0000)
And add links to the new shared libs section.

docs/users_guide/packages.xml
docs/users_guide/phases.xml
docs/users_guide/win32-dlls.xml

index 0d7a02f..8d668f9 100644 (file)
@@ -393,8 +393,9 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf:</screen>
          <literal>&ndash;all_load</literal> on MacOS X)</para>
       </listitem>
       <listitem>
-       <para>When building the package as shared object, GHC wraps
-         out the underlying linker so that the user gets a common
+       <para>When building the package as shared library, GHC can be used to
+         perform the link step. This hides some of the details
+         out the underlying linker and provides a common
          interface to all shared object variants that are supported
          by GHC (DLLs, ELF DSOs, and Mac OS dylibs). The shared
          object must be named in specific way for two reasons: (1)
index ac71b97..2026a34 100644 (file)
@@ -642,12 +642,10 @@ $ cat foo.hspp</screen>
         </term>
         <listitem>
           <para>Generate position-independent code (code that can be put into
-          shared libraries). This currently works on Mac OS X; it works on
-          PowerPC Linux when using the native code generator (-fasm).
-          It is not quite ready to be used yet for x86 Linux.
-          On Windows, position-independent code is never used,
-          and on PowerPC64 Linux, position-independent code is always used,
-          so the flag is a no-op on those platforms.</para>
+          shared libraries). This currently works on Linux x86 and x86-64 when
+          using the native code generator (-fasm).
+          On Windows, position-independent code is never used
+          so the flag is a no-op on that platform.</para>
         </listitem>
       </varlistentry>
 
@@ -659,8 +657,8 @@ $ cat foo.hspp</screen>
           <para>When generating code, assume that entities imported from a
           different package will reside in a different shared library or
           binary.</para>
-          <para>Note that this option also causes GHC to use shared libraries
-          when linking.</para>
+          <para>Note that using this option when linking causes GHC to link
+         against shared libraries.</para>
         </listitem>
       </varlistentry>
     </variablelist>
@@ -825,8 +823,10 @@ $ cat foo.hspp</screen>
           <indexterm><primary><option>-dynamic</option></primary></indexterm>
         </term>
         <listitem>
-          <para>This flag switches to shared Haskell libraries for
-          linking. See <xref linkend="building-packages" /> on how to
+          <para>This flag tells GHC to link against shared Haskell libraries.
+         This flag only affects the selection of dependent libraries, not
+         the form of the current target (see -shared).
+         See <xref linkend="using-shared-libs" /> on how to
           create them.</para>
 
           <para>Note that this option also has an effect on
index 703bb18..8cd73ec 100644 (file)
@@ -210,7 +210,8 @@ make-sessions running under cygwin.
 
 <para>
 <emphasis>Making Haskell libraries into DLLs doesn't work on Windows at the
-moment; we hope to re-instate this facility in the future.  Note that
+moment; we hope to re-instate this facility in the future
+(see <xref linkend="using-shared-libs"/>).  Note that
 building an entire Haskell application as a single DLL is still supported: it's
        just multi-DLL Haskell programs that don't work.  The Windows
        distribution of GHC contains static libraries only.</emphasis></para>