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. +