X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fshared_libs.xml;h=def773c0a8ad8c02502b5ed6a3c52109355ab4dc;hb=4d8c7c976104d2e39a1183967ec0f254a0fc0a47;hp=00f6f67792c3f791cfd4a8ad32c94a8e35546acf;hpb=5364ea8bd2086d3ce973988d583e3b4585d37b4d;p=ghc-hetmet.git
diff --git a/docs/users_guide/shared_libs.xml b/docs/users_guide/shared_libs.xml
index 00f6f67..def773c 100644
--- a/docs/users_guide/shared_libs.xml
+++ b/docs/users_guide/shared_libs.xml
@@ -218,17 +218,6 @@ ghc -dynamic -shared Foo.o -o libfoo.so
-
- wrapped
-
-
- 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.
-
-
-
To use relative paths for dependent libraries on Linux and Solaris you
can use the deploy 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. -optl-Wl,-rpath,'$ORIGIN/lib'.
+
+ 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
+ -dylib-install-name option (which passes
+ -install_name 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.
+