From f08ed233619bd5dc2e56a68169c2da9693f605ee Mon Sep 17 00:00:00 2001 From: Olly Betts Date: Sat, 20 May 2006 09:03:29 +0000 Subject: [PATCH] Typo fixes. git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@9128 626c5289-ae23-0410-ae9c-e8d60b6d4f22 --- Doc/Manual/Modules.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Doc/Manual/Modules.html b/Doc/Manual/Modules.html index a2359ef1b..a687edc1b 100644 --- a/Doc/Manual/Modules.html +++ b/Doc/Manual/Modules.html @@ -82,7 +82,7 @@ languages provide. One solution is to load all modules before spawning any thre

As described in The run-time type checker, the functions SWIG_TypeQuery, SWIG_NewPointerObj, and others sometimes need to be called. Calling these functions from a typemap is supported, since the typemap code -is embedded into the _wrap.c file, which has those declerations available. If you need +is embedded into the _wrap.c file, which has those declarations available. If you need to call the SWIG run-time functions from another C file, there is one header you need to include. To generate the header that needs to be included, run the following command: @@ -94,7 +94,7 @@ $ swig -python -external-runtime <filename> be something like swigpyrun.h, depending on the language. This header file should be treated like any of the other _wrap.c output files, and should be regenerated when the _wrap files are. After including this header, your code will be able to call SWIG_TypeQuery, -SWIG_NewPointerObj, SWIG_ConvertPtr and others. The exact argument paramaters +SWIG_NewPointerObj, SWIG_ConvertPtr and others. The exact argument parameters for these functions might differ between language modules; please check the language module chapters for more information.

@@ -104,7 +104,7 @@ need to link against the language libraries like libpython-2.3). Data is shared file and the _wrap.c files through a global variable in the scripting language. It is also possible to copy this header file along with the generated wrapper files into your own package, so that you can distribute a package that can be compiled without SWIG installed (this works -because the header file is self contained, and does not need to link with anything).

+because the header file is self-contained, and does not need to link with anything).

15.3 A word of caution about static libraries

@@ -114,7 +114,7 @@ When working with multiple SWIG modules, you should take care not to use static libraries. For example, if you have a static library libfoo.a and you link a collection of SWIG modules with that library, each module will get its own private copy of the library code inserted into it. This is very often NOT what you want and it can lead to unexpected or bizarre program -behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libaries. +behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.

15.4 References