Hi Ralf, 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) : 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. Do you give me your approval to try to reformulate and correct this part ? * 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. 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. 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. Best regards, -- Jeremie LE HEN aka TtZ/TataZ [EMAIL PROTECTED] [EMAIL PROTECTED] Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool