"Representable0" -> "Generic" in the user's guide.

[ghc-hetmet.git] / docs / users_guide / shared_libs.xml

diff --git a/docs/users_guide/shared_libs.xml b/docs/users_guide/shared_libs.xml
index 00f6f67..89b656a 100644 (file)
--- a/docs/users_guide/shared_libs.xml
+++ b/docs/users_guide/shared_libs.xml
@@ -16,7 +16,7 @@
     shared between several programs. In contrast, with static linking the
     code is copied into each program. Using shared libraries can thus save
     disk space. They also allow a single copy of code to be shared in memory
     shared between several programs. In contrast, with static linking the
     code is copied into each program. Using shared libraries can thus save
     disk space. They also allow a single copy of code to be shared in memory

-    between several programs that use it. Shared libraires are often used as
+    between several programs that use it. Shared libraries are often used as

     a way of structuring large projects, especially where different parts are
     written in different programming languages. Shared libraries are also
     commonly used as a plugin mechanism by various applications. This is
     a way of structuring large projects, especially where different parts are
     written in different programming languages. Shared libraries are also
     commonly used as a plugin mechanism by various applications. This is

@@ -218,17 +218,6 @@ ghc -dynamic -shared Foo.o -o libfoo.so
            </para>
          </listitem>
        </varlistentry>
            </para>
          </listitem>
        </varlistentry>

-       <varlistentry>
-         <term>wrapped</term>
-         <listitem>
-           <para>
-             This mode generates a wrapper program which in turn calls the
-             real program (in the same directory but with a .dyn extension)
-             in such a way that it can find the shared libraries that it
-             needs. At the current time this mode is somewhat experimental.
-           </para>
-         </listitem>
-       </varlistentry>

       </variablelist>
       To use relative paths for dependent libraries on Linux and Solaris you
       can use the <literal>deploy</literal> mode and pass suitable a -rpath
       </variablelist>
       To use relative paths for dependent libraries on Linux and Solaris you
       can use the <literal>deploy</literal> mode and pass suitable a -rpath

@@ -242,6 +231,19 @@ ghc -dynamic Main.hs -o main -lfoo -L. -optl-Wl,-rpath,'$ORIGIN'
       Similarly it would be possible to use a subdirectory relative to the
       executable e.g. <literal>-optl-Wl,-rpath,'$ORIGIN/lib'</literal>.
     </para>
       Similarly it would be possible to use a subdirectory relative to the
       executable e.g. <literal>-optl-Wl,-rpath,'$ORIGIN/lib'</literal>.
     </para>

+    <para>
+      The standard assumption on Darwin/MacOS X is that dynamic libraries will
+      be stamped at build time with an "install name", which is the full
+      ultimate install path of the library file. Any libraries or executables
+      that subsequently link against it (even if it hasn't been installed yet)
+      will pick up that path as their runtime search location for it. When
+      compiling with ghc directly, the install name is set by default to the
+      location where it is built. You can override this with the
+      <literal>-dylib-install-name</literal> option (which passes
+      <literal>-install_name</literal> to the Apple linker). Cabal does this
+      for you. It automatically sets the install name for dynamic libraries to
+      the absolute path of the ultimate install location.
+    </para>

   </sect2>
 
 </sect1>
   </sect2>
 
 </sect1>