Re: libtool question

[Bob Friesenhahn]

On Mon, 1 May 2006, Bob Rossi wrote:
> gdbmi used to use AC_PROG_RANLIB. By doing this, it would create a
> libgdbmi.a and the CGDB package would do
>
> cgdb_LDFLAGS = \
> -L$(top_builddir)/lib/gdbmi/src
>
> cgdb_DEPENDENCIES = \
> $(top_srcdir)/lib/gdbmi/src
>
> cgdb_LDADD = ... -lgdbmi ...
>
> My first question is, does it even make sense for the cgdb Makefile.am
> files to use the LDFLAGS, DEPENDENCIES and LDADD variables for a library
> that is created in a sub configure.in? If this isn't the way to do it,
> what is?

This is a common error that I have seen in a few packages.  The proper 
approach for a libtool library built under the same source tree is to 
list the path to the .la file in the subdirectory.  That way 
Automake and libtool take care of everything needed to use the 
library.  With the approach you describe, automake is not properly 
aware of the library.

For example

cgdb_LDADD = $(top_srcdir)/lib/gdbmi/src/libgdbmi.la

This should usually eliminate the need for adding anything for the 
library in cgdb_DEPENDENCIES or cgdb_LDFLAGS.

> My second question is, now that I'm switching over to libtool, can I
> still depend on the libgdbmi.a file to be in the gdbmi builddir after I
> type make? It seems as if libtool creates the libraries during the 'make
> install' instead of during the make phase.

Libtool should be creating the libraries during the 'make' phase, but 
sometimes it needs to re-link the libraries during the 'make install' 
phase.

There is not always a static library at all.  For example, your 
package may build as a shared library, and the person who ran 
configure may decide to not build the static version.

If you always need the effect of a private static library (which is 
never installed), then you can use a libtool convenience library 
instead.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/