Re: static lib with libtool 1.5

[Jeremie LE HEN]

Hi Ralf,

> Sorry for the late response, I've been away.

Once again, sorry for the late response :-).


I made the changes we talked about in our previous mails.  Here are a
few notes :

        - I wanted to install the freshly checked-out branch-2-0 from
          CVS, in order to give real examples of the libtool output.
          This was really a pain.  I've ran into several obscure issues
          that finally prevented me from having it installed.  Thus the
          given examples come from libtool-1.5.18.
          Neverthless, I strongly advice you to make this simpler,
          because I think this may discourage number of peoples who
          are willing to work on libtool.
        
        - Since I have no access to a box which doesn't support shared
          libraries.  Thus to emulate such a behaviour, I compiled
          libtool-1.5.18 with --disabled-shared.

        - The attached patches are against the documentation in HEAD.

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

The ``libtool_part3.1.diff'' patch corrects this part.  There is one
point that I'm not sure about : when compiling on a system which doesn't
support shared libraries, it seems there is only one object file
createdi (for what I observed).  My confusion comes from the fact that
before my patch it was stated that the same object file file should be
created twice.

This patch also replaces the obsolete syntax "libtool compile" with the
new one "libtool --mode==compile" in section 3.1 examples.

> > * 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.  :)

I corrected the the section 3.2 to avoid some ambiguities in
``libtool_part3.2.diff''.  I also explained the consequences of
using ``libhello.a'' instead of ``libhello.la'' when building
a static library only.

This patch also replaces the obsolete syntax in section 3.2.

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

The previous patch adds a small paragraph at the end of section 3.2
explaining the role of the `.la' file.


I didn't take care of other section, but those clearly need the be
changed from the obsolete syntaxe (libtool <mode>) to the new one
(libtool --mode=<mode>).  I can't do it blindly because I don't know
libtool well enough, but I guess a more experienced user or even a
developper could do this in a couple of minutes.

Please feel free to make comments on my documentation patches, I will be
glad to correct them if needed.

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?

libtool_part3.1.diff
Description: Text document

libtool_part3.2.diff
Description: Text document