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
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
