From b1cfe1372b27bd622bc6abd5da0e77a82633c068 Mon Sep 17 00:00:00 2001 From: Daniel Fischer Date: Mon, 30 May 2011 08:58:03 +0200 Subject: [PATCH] Fix typos in shared_libs.xml --- docs/users_guide/shared_libs.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/users_guide/shared_libs.xml b/docs/users_guide/shared_libs.xml index 29dcb37..5c258d4 100644 --- a/docs/users_guide/shared_libs.xml +++ b/docs/users_guide/shared_libs.xml @@ -113,8 +113,8 @@ ghc --make -dynamic Main.hs Building Haskell code into a shared library is a good way to include Haskell code in a larger mixed-language project. While with static linking it is recommended to use GHC to perform the final link step, - with shared libaries a Haskell library can be treated just like any - other shared libary. The linking can be done using the normal system C + with shared libraries a Haskell library can be treated just like any + other shared library. The linking can be done using the normal system C compiler or linker. @@ -138,7 +138,7 @@ ghc --make -dynamic -shared -fPIC Foo.hs -o libfoo.so package. The -fPIC flag is required for all code that will end up in a shared library. The -shared flag specifies to make a shared library rather than a program. To make - this clearer we can break this down into separate compliation and link + this clearer we can break this down into separate compilation and link steps: ghc -dynamic -fPIC -c Foo.hs @@ -179,7 +179,7 @@ ghc -dynamic -shared Foo.o -o libfoo.so is to use a "runtime path" or "rpath" embedded into programs and libraries themselves. These paths can either be absolute paths or on at least Linux and Solaris they can be paths relative to the program or - libary itself. In principle this makes it possible to construct fully + library itself. In principle this makes it possible to construct fully relocatable sets of programs and libraries. -- 1.7.10.4