Re: static lib with libtool 1.5

[Ralf Wildenhues]

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