Re: Building a Shared Library

[Tim Van Holder]

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....