diff options
Diffstat (limited to 'doc/libtool.texi')
| -rw-r--r-- | doc/libtool.texi | 56 |
1 files changed, 28 insertions, 28 deletions
diff --git a/doc/libtool.texi b/doc/libtool.texi index c06ddaae..557a19d2 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -654,7 +654,7 @@ also that we need to add @option{-lm} to the link command line because libtool}). Another complication in building shared libraries is that we need to -specify the path to the directory in which they (eventually) will be +specify the path to the directory wher they will (eventually) be installed (in this case, @file{/usr/local/lib})@footnote{If you don't specify an @code{rpath}, then libtool builds a libtool convenience archive, not a shared library (@pxref{Static libraries}).}: @@ -1321,7 +1321,7 @@ Print libtool version information and exit. @end table The current @command{libtool} implementation is done with a shell script -that needs to be invoked by the shell which @command{configure} chose for +that needs to be invoked by the shell that @command{configure} chose for configuring @command{libtool} (@pxref{config.status Invocation, , The Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in the she-bang (@samp{#!}) line of the @command{libtool} script. Using a @@ -1538,7 +1538,7 @@ to keep those files created with @code{gcc -ftest-coverage} for example. @item -release @var{release} Specify that the library was generated by release @var{release} of your -package, so that users can easily tell which versions are newer than +package, so that users can easily tell what versions are newer than others. Be warned that no two releases of your package will be binary compatible if you use this flag. If you want binary compatibility, use the @option{-version-info} flag instead (@pxref{Versioning}). @@ -1714,7 +1714,7 @@ For systems where fast installation cannot be turned on, relinking may be needed. In this case, a @samp{DESTDIR} install will fail. Currently it is not generally possible to install into a temporary -staging area that contains needed third-party libraries which are +staging area that contains needed third-party libraries that are not yet visible at their final location. @end table @@ -1775,7 +1775,7 @@ The remaining @var{mode-args} are either flags for the deletion program This chapter describes how to integrate libtool with your packages so that your users can install hassle-free shared libraries. -There are several ways in which Libtool may be integrated in your +There are several ways that Libtool may be integrated in your package, described in the following sections. Typically, the Libtool macro files as well as @file{ltmain.sh} are copied into your package using @command{libtoolize} and @command{aclocal} after setting up the @@ -1873,7 +1873,7 @@ machine, if any. @end defmac @defmac LT_LIB_DLLOAD -This is the macro used by @samp{libltdl} to determine which dlloaders +This is the macro used by @samp{libltdl} to determine what dlloaders to use on this machine, if any. Several shell variables are set (and @samp{AC_SUBST}ed) depending on the dlload interfaces are available on this machine. @samp{LT_DLLOADERS} contains a list of libtool @@ -2799,7 +2799,7 @@ we should use the C++ compiler instead. @item C++ compilers will link some Standard C++ library in by default, but -libtool does not know which are these libraries, so it cannot even run +libtool does not know what these libraries are, so it cannot even run the inter-library dependence analyzer to check how to link it in. Therefore, running @command{ld} to link a C++ program or library is deemed to fail. @@ -2837,7 +2837,7 @@ correspondence between language names and tags names. @item Windows Resource @tab RC @end multitable -@command{libtool} tries to automatically infer which tag to use from +@command{libtool} tries to automatically infer what tag to use from the compiler command being used to compile or link. If it can't infer a tag, then it defaults to the configuration for the @code{C} language. @@ -3054,7 +3054,7 @@ may also be replaced by other libraries using it. @section Managing release information Often, people want to encode the name of the package release into the -shared library so that it is obvious to the user which package their +shared library so that it is obvious to the user what package their programs are linked against. This convention is used especially on GNU/Linux: @@ -3294,7 +3294,7 @@ By definition, every shared library system provides a way for executables to depend on libraries, so that symbol resolution is deferred until runtime. -An @dfn{inter-library dependency} is one in which a library depends on +An @dfn{inter-library dependency} is where a library depends on other libraries. For example, if the libtool library @file{libhello} uses the @code{cos} function, then it has an inter-library dependency on @file{libm}, the math library that implements @code{cos}. @@ -3832,7 +3832,7 @@ Note that libltdl is not well tested in a multithreaded environment, though the intention is that it should work (@pxref{Thread Safety in libltdl, , Using libltdl in a multi threaded environment}). It was reported that GNU/Linux's glibc 2.0's @code{dlopen} with -@samp{RTLD_LAZY} (which libltdl uses by default) is not thread-safe, +@samp{RTLD_LAZY} (that libltdl uses by default) is not thread-safe, but this problem is supposed to be fixed in glibc 2.1. On the other hand, @samp{RTLD_NOW} was reported to introduce problems in multi-threaded applications on FreeBSD@. Working around these problems @@ -3959,7 +3959,7 @@ transparently. @deftypefun lt_dlhandle lt_dlopenadvise (const char *@var{filename}, @w{lt_dladvise @var{advise}}) The same as @code{lt_dlopen}, except that it also requires an additional -argument which may contain additional hints to the underlying system +argument that may contain additional hints to the underlying system module loader. The @var{advise} parameter is opaque and can only be accessed with the functions documented below. @@ -4662,7 +4662,7 @@ to include libltdl in the distribution of your package, for the convenience of users of your package that don't have libtool or libltdl installed, or if you are using features of a very new version of libltdl that you don't expect your users to have yet. In such -cases, you must decide which flavor of libltdl you want to use: a +cases, you must decide what flavor of libltdl you want to use: a convenience library or an installable libtool library. The most simplistic way to add @code{libltdl} to your package is to @@ -5244,7 +5244,7 @@ works properly. @pindex demo-hardcode.test On all systems with shared libraries, the location of the library can be encoded in executables that are linked against it @pxref{Linking -executables}. This test checks the conditions under which your system +executables}. This test checks under what conditions your system linker hardcodes the library location, and guarantees that they correspond to libtool's own notion of how your linker behaves. @@ -5595,7 +5595,7 @@ a normal program. When the test is invoked in this way, it produces output that may be useful in determining what the problem is. The new, Autotest-based test suite produces as output a file -@file{tests/testsuite.log} which contains information about failed +@file{tests/testsuite.log} that contains information about failed tests. You can pass options to the test suite through the @command{make} @@ -5695,7 +5695,7 @@ This page usually describes how to install shared libraries. @item output from @kbd{ls -l /lib /usr/lib} This shows the naming convention for shared libraries on the system, -including which names should be symbolic links. +including what names should be symbolic links. @item any additional documentation Some systems have special documentation on how to build and install @@ -5762,7 +5762,7 @@ future. @item pass_all @vindex pass_all will pass everything without any checking. This may work on platforms -in which code is position-independent by default and inter-library +where code is position-independent by default and inter-library dependencies are properly supported by the dynamic linker, for example, on DEC OSF/1 3 and 4. @@ -5931,7 +5931,7 @@ objects. @node Multiple dependencies @subsection Multiple dependencies -On most modern platforms the order in which dependent libraries are listed +On most modern platforms the order where dependent libraries are listed has no effect on object generation. In theory, there are platforms that require libraries that provide missing symbols to other libraries to be listed after those libraries whose symbols they provide. @@ -5964,8 +5964,8 @@ use the @code{ar ts} command, instead. Most build systems support the ability to compile libraries and applications on one platform for use on a different platform, provided a compiler capable of generating the appropriate output is available. In such cross compiling -scenarios, the platform on which the libraries or applications are compiled -is called the @dfn{build platform}, while the platform on which the libraries +scenarios, the platform where the libraries or applications are compiled +is called the @dfn{build platform}, while the platform where the libraries or applications are intended to be used or executed is called the @dfn{host platform}. @ref{GNU Build System,, The GNU Build System, automake, The Automake Manual}, @@ -5986,7 +5986,7 @@ to the differences between the two platforms. In addition to cases where the host platform and build platform are extremely similar (e.g. @samp{i586-pc-linux-gnu} and @samp{i686-pc-linux-gnu}), there is -another case in which cross-compiled host applications may be executed on the +another case where cross-compiled host applications may be executed on the build platform. This is possible when the build platform supports an emulation or API-enhanced environment for the host platform. One example of this situation would be if the build platform were MinGW, and the host platform were @@ -6212,7 +6212,7 @@ required. @xref{LT_CYGPATH}. @uref{http://www.winehq.org/, Wine} provides an interpretation environment for -some Unix platforms in which Windows applications can be executed. It provides +some Unix platforms where Windows applications can be executed. It provides a mapping between the Unix file system and a virtual Windows file system used by the Windows programs. For the file name conversion to work, Wine must be installed and properly configured on the build platform, and the @@ -6247,7 +6247,7 @@ coexist within the same Windows instance. Each installation will have separate names and paths to Cygwin form. Each installation's @command{cygpath} utility automatically deduces the appropriate @file{/etc/fstab} file. Since each @file{@var{CYGROOT-N}/etc/fstab} mount table may specify different mappings, it -matters which @command{cygpath} is used. +matters what @command{cygpath} is used. Note that @command{cygpath} is a Cygwin application; to execute this tool from Unix requires a working and properly configured Wine installation, as well @@ -6450,7 +6450,7 @@ of contemporary GNU tools. It should be noted that the GNU auto-export feature is turned off when an explicit @code{__declspec(dllexport)} is seen. The GNU tools do this to not make more symbols visible for projects that have already taken the trouble to decorate symbols. There is no -similar way to limit which symbols are visible in the code when Libtool +similar way to limit what symbols are visible in the code when Libtool is using Microsoft tools. In order to limit symbol visibility in that case you need to use one of the options @option{-export-symbols} or @option{-export-symbols-regex}. @@ -6465,10 +6465,10 @@ When the objects that form the library are built, there are generally two copies built for each object. One copy is used when linking the DLL and one copy is used for the static library. On Windows systems, a pair of defines are commonly used to discriminate how the interface symbols -should be decorated. The first define is @samp{-DDLL_EXPORT} which is +should be decorated. The first define is @samp{-DDLL_EXPORT}, which is automatically provided by Libtool when @command{libtool} builds the copy of the object that is destined for the DLL. The second define is -@samp{-DLIBFOO_BUILD} (or similar) which is often added by the package +@samp{-DLIBFOO_BUILD} (or similar), which is often added by the package providing the library and is used when building the library, but not when consuming the library. @@ -7032,7 +7032,7 @@ Commands to create a reloadable object. Set @code{reload_cmds} to @end defvar @defvar runpath_var -The environment variable that tells the linker which directories to +The environment variable that tells the linker what directories to hardcode in the resulting executable. @end defvar @@ -7088,7 +7088,7 @@ If the toolchain is not native to the build platform (e.g.@: if you are using MSYS to drive the scripting, but are using the MinGW native Windows compiler) this variable describes how to convert file names from the format used by the build platform to the format used by host platform. Normally set to -@samp{func_convert_file_noop}, libtool will autodetect most cases in which +@samp{func_convert_file_noop}, libtool will autodetect most cases where other values should be used. On rare occasions, it may be necessary to override the autodetected value (@pxref{Cygwin to MinGW Cross}). @end defvar |