Hi Nicolas,
* Nicolas Kaiser wrote on Wed, Dec 14, 2005 at 04:07:16PM CET:
> Some documentation typos.
Thanks! Applied to branch-1-5 (all fixed in HEAD already).
Cheers,
Ralf
2005-12-16 Nicolas Kaiser <[EMAIL PROTECTED]>
* doc/libtool.texi: Fix some documentation typos.
Index: doc/libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.134.2.13
diff -u -r1.134.2.13 libtool.texi
--- doc/libtool.texi 29 Aug 2005 11:11:41 -0000 1.134.2.13
+++ doc/libtool.texi 16 Dec 2005 18:05:17 -0000
@@ -1085,10 +1085,10 @@
@item [EMAIL PROTECTED]
Use @var{mode} as the operation mode. If not specified, an attempt is
-made to inferr the operation mode from the @var{mode-args}. Not specifying
+made to infer the operation mode from the @var{mode-args}. Not specifying
the @var{mode} is currently deprecated, as there are too many situations
where it is not possible to guess. Future versions of Libtool will require
-that @var{mode} be explicity set.
+that @var{mode} be explicitly set.
@var{mode} must be set to one of the following:
@@ -1157,7 +1157,7 @@
and @samp{-Xcompiler @var{flag}}.
If both PIC and non-PIC objects are being built, libtool will normally
-supress the compiler output for the PIC object compilation to save
+suppress the compiler output for the PIC object compilation to save
showing very similar, if not identical duplicate output for each
object. If the @samp{-no-suppress} option is given in compile mode,
libtool will show the compiler output for both objects.
@@ -3086,7 +3086,7 @@
which will be called at the start of parts of the libltdl implementation
code which require a mutex lock.
-Because libltdl is inherantly recursive, it is important that the
+Because libltdl is inherently recursive, it is important that the
locking mechanism employed by these callback functions are reentrant, or
else strange problems will occur.
@end deftypefn
@@ -3110,13 +3110,13 @@
The type of a matching callback function to retrieve the last stored
error message from thread local storage.
-When regeistered correctly this function will be used by
+When registered correctly this function will be used by
@code{lt_dlerror())} from all threads to retrieve error messages for the
client.
@end deftypefn
@deftypefn {Function} int lt_dlmutex_register (@w{lt_dlmutex_lock [EMAIL
PROTECTED], @w{lt_dlmutex_unlock [EMAIL PROTECTED], @w{lt_dlmutex_set_error
[EMAIL PROTECTED], @w{lt_dlmutex_geterror [EMAIL PROTECTED])}
-Use this function to register one of each of function ttypes described
+Use this function to register one of each of function types described
above in preparation for multi-threaded use of libltdl. All arguments
must be valid [EMAIL PROTECTED] function addresses, or else all
@code{NULL} to return to single threaded operation.
@@ -3319,7 +3319,7 @@
@deftypefn {Type} int lt_module_close (@w{lt_user_data @var{loader_data},}
@w{lt_module @var{module}})
The type of the unloader function for a user defined module loader.
-Implementatation of such a function should attempt to release
+Implementation of such a function should attempt to release
any resources tied up by the @var{module} module, and then unload it
from memory. If the function fails for some reason, set the error
message with @code{lt_dlseterror} and return non-zero.
@@ -3481,7 +3481,7 @@
@deftypefun int lt_dlseterror (@w{int @var{errorcode}})
When writing your own module loaders, you should use this function to
-raise errors so that they are propogated through the @code{lt_dlerror}
+raise errors so that they are propagated through the @code{lt_dlerror}
interface. All of the standard errors used by libltdl are declared in
@file{ltdl.h}, or you can add more of your own with
@code{lt_dladderror}. This function returns 0 on success.
