Mainly a few minor language nits; I'm not a native English speaker either, so feel free to correct me if my "feel" is off.
> Building shared libraries is a relatively complex matter. For this Maybe make this 'Portably building shared libraries...' - if portability isn't an issue, building shared libraries tends to be easy. > Presentation of Libtool Maybe "What is Libtool?", or "The Libtool Concept". > Actually, Libtool abstracts shared and static libraries into an unified 'a unified' - since 'u' is pronounced 'you', it does not count as a vowel for rules like this. > shared library, or maybe both. What exactly it is, you cannot know Maybe "Their exact nature cannot be determined until `./configure'-time:..."? > Because object files for shared and static libraries must be compiled > differently, Libtool also uses its own abstraction: "Libtool objects". "... its own abstraction for those: ..." > These are files ending with the `.lo' suffix. Libtool libraries are Maybe "using the ... suffix" for consistency with the preceding paragraph. > `LTLIBRARIES' primary. Each `_LTLIBRARIES' variable is a list of > Libtool library to build. For instance, to create a Libtool library "a list of Libtool libraries" > Building conditional Libtool libraries I'd say "Conditionally building..." but since there is a Conditional Programs topic, I assume the Automake manual considers the targets, and not their build, to be conditional. > As for conditional programs (*note Conditional Programs::), there are "As for..." tends to be equivalent to "Concernant..."; perhaps use "Like conditional ..." or "Similar to conditional...". > two main ways to build conditonal libraries: using Automake "conditional" > The important implementation detail you have to know is that the perhaps use "be aware of" instead of "know" > For libraries whose destinations directory is known by the time "destination directory"; "at the time..." or "at Automake time" > mentioned in `EXTRA_LTLIBRARIES'), Automake does not know the eventual "eventual" -> "final" > installation directory. For such libraries you must add the `-rpath' > option to the appropriate `_LDFLAGS' variable by hand. Maybe drop the "by hand" and just say "you must manually add" > You can see this difference by comparing these two ways to build > Libtool libraries conditionally. "The examples below illustrate the differences between these two methods."? > Sometime you want to build Libtool libraries which are not to be "Sometimes"; "are not to be" -> "will not be" or "should not be" > usually used to encapsulate many sublibraries, latter gathered into one "usually" -> "typically" (to avoid the double us*); "latter" -> "later" > built explicitely: Automake outputs rules to build them, but if the "explicitly" > library does not appears as a Makefile dependency anywhere it won't be "does not appear" > Here is an sample setup merging Libtool convenience libraries from "a sample" > The `created with both libtool and without' issue > ------------------------------------------------- > > Sometimes, the same source file is used both to build a > Libtool library > and to build a program or another (non Libtool) library. Maybe "... is used to build both a Libtool library and a non-Libtool target (be it a program or another library)". > assume we really want to keep these program and library separate.) Either "keep these separate" or "keep program and library separate". > `prog', and `foo.lo' for `libfoo.la'. The problem is that > when Libtool creates `foo.lo' it can erase `foo.$(OBJEXT)', > and we really cannot help it. "The problem is that in the course of creating `foo.lo', Libtool may erase (or replace) `foo.$(OBJEXT)' -- and this cannot be avoided." > with a message such as > object `foo.lo' created both with libtool and without Shouldn't the message be that foo.$(OBJEXT) is created in both cases? The program never builds foo.lo, but it does build foo.$(OBJEXT) > A work around to this issue is to ensure that these two objects get "workaround for this issue" > different basenames. As explained in *note renamed objects::, this This crossref will likely end up badly in a printed manual (though that would be easier to see if you posted the texinfo source): As explained in see Chapter 37.8: Renamed Objects, page 17, this....
