Re: static lib with libtool 1.5

[Jeremie LE HEN]

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                      address@hidden
                                                             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?