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 [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?
? .libtool.texi.swp
? <
? cvs.diff
? libtool.html
Index: libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.192
diff -u -p -u -r1.192 libtool.texi
--- libtool.texi 30 Apr 2005 09:30:14 -0000 1.192
+++ libtool.texi 11 Aug 2005 11:09:22 -0000
@@ -497,29 +497,29 @@ position-dependent code.
@cindex @samp{.lo} files
@cindex object files, library
Since this is a library implementation detail, libtool hides the
-complexity of PIC compiler flags by using separate library object files
-(that end in @samp{.lo} instead of @samp{.o}). On systems without shared
-libraries (or without special PIC compiler flags), these library object
-files are identical to ``standard'' object files.
+complexity of PIC compiler flags and uses separate library object files
+(the PIC one lives in the @[EMAIL PROTECTED] subdirectory and the
+static one lives in the current directory). On systems without shared
+libraries (or without special PIC compiler flags), the PIC library object
+files are not created.
To create library object files for @file{foo.c} and @file{hello.c},
simply invoke libtool with the standard compilation command as
arguments (@pxref{Compile mode}):
@example
-a23$ @kbd{libtool compile gcc -g -O -c foo.c}
+a23$ @kbd{libtool --mode=compile gcc -g -O -c foo.c}
gcc -g -O -c foo.c -o foo.o
-a23$ @kbd{libtool compile gcc -g -O -c hello.c}
+a23$ @kbd{libtool --mode=compile gcc -g -O -c hello.c}
gcc -g -O -c hello.c -o hello.o
a23$
@end example
-Note that libtool silently creates an additional control file for each
+Note that libtool silently creates an additional control file on each
@samp{compile} invocation. The @samp{.lo} file is the libtool object,
which Libtool uses to determine what object file may be built into a
-shared library, and the @samp{.o} file is a standard object file. On
[EMAIL PROTECTED], only static libraries are supported so the library objects
-look like this:
+shared library. On @samp{a23}, only static libraries are supported so
+the library objects look like this:
@example
# foo.lo - a libtool object file
@@ -540,13 +540,16 @@ additional PIC object by inserting the a
flags into the compilation command:
@example
-burger$ @kbd{libtool compile gcc -g -O -c foo.c}
+burger$ @kbd{libtool --mode=compile gcc -g -O -c foo.c}
mkdir @value{objdir}
gcc -g -O -c foo.c -fPIC -DPIC -o @value{objdir}/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
burger$
@end example
+Note that Libtool automatically created @[EMAIL PROTECTED] directory
+upon its first execution, where PIC library object files will be stored.
+
Since @samp{burger} supports shared libraries, and requires PIC
objects to build them, Libtool has compiled a PIC object this time,
and made a note of it in the libtool object:
@@ -573,7 +576,7 @@ inside @samp{#ifdef PIC} for example), y
the @option{-no-suppress} option to libtool's compile mode:
@example
-burger$ @kbd{libtool compile gcc -no-suppress -g -O -c hello.c}
+burger$ @kbd{libtool --mode=compile gcc -no-suppress -g -O -c hello.c}
gcc -g -O -c hello.c -fPIC -DPIC -o @value{objdir}/hello.o
gcc -g -O -c hello.c -o hello.o
burger$
Index: libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.192
diff -u -p -u -r1.192 libtool.texi
--- libtool.texi 30 Apr 2005 09:30:14 -0000 1.192
+++ libtool.texi 11 Aug 2005 11:38:49 -0000
@@ -609,22 +612,30 @@ shared libraries, libtool simply acts as
@cindex libtool libraries
@cindex @samp{.la} files
-Again, the libtool library name differs from the standard name (it has a
[EMAIL PROTECTED] suffix instead of a @samp{.a} suffix). The arguments to
+Again, the libtool control file name (@samp{.la} suffix) differs from
+the standard library name (@samp{.a} suffix). The arguments to
libtool are the same ones you would use to produce an executable named
@file{libhello.la} with your compiler (@pxref{Link mode}):
@example
-a23$ @kbd{libtool link gcc -g -O -o libhello.la foo.o hello.o}
-libtool: cannot build libtool library `libhello.la' from non-libtool \
- objects
+a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o}
+*** Warning: Linking the shared library libhello.la against the non-libtool
+*** objects foo.o hello.o is not portable!
+ar cru .libs/libhello.a
+ranlib .libs/libhello.a
+creating libhello.la
+(cd .libs && rm -f libhello.la && ln -s ../libhello.la libhello.la)
a23$
@end example
Aha! Libtool caught a common [EMAIL PROTECTED] trying to build a library
-from standard objects instead of library objects. This doesn't matter
-so much for static libraries, but on shared library systems, it is of
-great importance.
+from standard objects instead of special @samp{.lo} object files. This
+doesn't matter so much for static libraries, but on shared library
+systems, it is of great importance. (Note that you may replace
[EMAIL PROTECTED] with @samp{libhello.a} in which case : Libtool won't
+issue the warning any more. But although this method works, this is
+not intended to be used be cause it makes you lose the benefits of
+using Libtool.)
So, let's try again, this time with the library object files. Remember
also that we need to add @option{-lm} to the link command line because
@@ -638,7 +649,7 @@ specify an @code{rpath}, then libtool bu
archive, not a shared library (@pxref{Static libraries}).}:
@example
-a23$ @kbd{libtool link gcc -g -O -o libhello.la foo.lo hello.lo \
+a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
-rpath /usr/local/lib -lm}
ar cru @value{objdir}/libhello.a foo.o hello.o
ranlib @value{objdir}/libhello.a
@@ -650,7 +661,7 @@ a23$
Now, let's try the same trick on the shared library platform:
@example
-burger$ @kbd{libtool link gcc -g -O -o libhello.la foo.lo hello.lo \
+burger$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
-rpath /usr/local/lib -lm}
rm -fr @value{objdir}/libhello.a @value{objdir}/libhello.la
ld -Bshareable -o @value{objdir}/libhello.so.0.0 foo.lo hello.lo -lm
@@ -671,6 +682,11 @@ subdirectory, rather than the current di
make it easier to clean up the build directory, and to help ensure that
other programs fail horribly if you accidentally forget to use libtool
when you should.
+
+Again, you may want to have a look at the @samp{.la} file in order
+to see what Libtool stores in it. In particular, you will see that
+Libtool uses this file to remember @samp{-rpath} argument as well as
+the dependancy on the math library (@samp{-lm}).
@node Linking executables
@section Linking executables
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
