[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: static lib with libtool 1.5
Jeremie LE HEN
Re: static lib with libtool 1.5
Wed, 20 Jul 2005 14:23:06 +0200
On Fri, Jul 01, 2005 at 05:02:46PM +0200, Ralf Wildenhues wrote:
> * Jeremie LE HEN wrote on Fri, Jul 01, 2005 at 03:29:55PM CEST:
> > > Your documentation points are valid, thanks. We should work on that.
> > You are welcome, I can update the documentation about these subjects if
> > someone points me out the documentation source file (maybe it's simply
> > the HTML file ?), and then send the diff here.
> Documentation is written in texinfo format. It will be easiest to pull
> the current docs from CVS, if you want to make changes. The libtool
> resp. texinfo homepages describe how to access the CVS repository. Note
> that the documentation from CVS branches branch-2-0/HEAD is much more up
> to date and contains much of what you are looking for, I believe.
First, sorry for the delay.
I began to read the documentation (from HEAD) again to make it clearer.
Here are a few notes :
* Section 3.1 ``Creating object file'' :
<< Since this is a library implementation detail, libtool hides the
complexity of PIC compiler flags by using separate library object
files (that end in `.lo' instead of `.o'). On systems without shared
libraries (or without special PIC compiler flags), these library
object files are identical to "standard" object files. >>
I am maybe misunderstanding this, but it appears to be in
contradiction with what is written below :
<< Note that libtool silently creates an additional control file for
each `compile' invocation. The `.lo' file is the libtool object,
which Libtool uses to determine what object file may be built into a
shared library, and the `.o' file is a standard object file. >>
IMO, the user is confused while reading this. Furthermore, the
first statement is wrong in regard to the example on the NetBSD box
burger$ libtool compile gcc -g -O -c foo.c
gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
Note that in this cas, the .lo control file is indeed created
silently as stated in the second sentence I pointed out. The PIC
library is stored in .libs/foo.o, not in foo.lo as the first
statement let understand.
Do you give me your approval to try to reformulate and correct this
* Section 3.2 ``Linking libraries'' :
This part of documentation states that .lo files should be used to
create libraries, little does it matter which kind of library the
user wants. OTOH, while reading section 3.3 ``Linking
executables'', "main.o" is used, instead of "main.lo". Is it
intended to show that libtool is able to work with object not issued
from libtool itself ? In this case I would like to express it
In section 3.1, it's explicitely explained that .lo files are
control files for objects (see above), modulo some confusion in
documentation (see above, again ;-). In the manner of this, I think
it would be worth to tell that .la files are control files for
libraries too. In this case, I would precise that .lo and .la
files help to recall things such as -rpath and -llib accross libtool
When libtool 2 is supposed to be out ? If it's planned to happen soon,
then I don't think backporting the --tag documentation to the branch-1-5
is worth enough. Otherwise, I would like to give a try to backport this
documentation, although I'm still don't fully understand --tag :-).
Thanks un advance for your comments.
Jeremie LE HEN aka TtZ/TataZ address@hidden
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?