Hi Jeremie,
Sorry for the late response, I've been away.
* Jeremie LE HEN wrote on Wed, Jul 20, 2005 at 02:23:06PM CEST:
>
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This part is wrong, as you noted correctly.
(Long long time ago, it used to be that way.)
> 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. >>
This is correct.
> IMO, the user is confused while reading this. Furthermore, the
> first statement is wrong in regard to the example on the NetBSD box
> (burger) :
> burger$ libtool compile gcc -g -O -c foo.c
> mkdir .libs
> 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
> burger$
>
> 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.
Full ACK.
> Do you give me your approval to try to reformulate and correct this
> part ?
Surely. I'll happily take a patch to a better formulation.
> * 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
> explicitly.
Well, main.o will not itself end up in a library, so no need to use
main.lo here. Strictly speaking. It would not harm to use main.lo.
It would be good to denote both of these thoughts in the manual, I
agree. :)
> 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
> calls.
I agree as well. However, as over time the contents of the files may be
extended, we should not limit ourselves to what they contain.
Otherwise, good idea.
> 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 :-).
There will be at least one more 1.5 release for pending necessary
forward compatibility. No, I don't know when either of these will be
ready. :)
Cheers,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
