[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool question

From: Bob Friesenhahn
Subject: Re: libtool question
Date: Mon, 1 May 2006 21:21:34 -0500 (CDT)

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 = \


cgdb_LDADD = ... -lgdbmi ...

My first question is, does it even make sense for the cgdb
files to use the LDFLAGS, DEPENDENCIES and LDADD variables for a library
that is created in a sub 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/

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]