Here's a slightly revised test. I removed the Makefile.am modification. libtool is still built by configure, but it is never removed. For a real life application, the libraries might appear in a subdirectory, rather than in the top level directory. Since lib_LTLIBRARIES is not necessary for creating libtool, lib_LTLIBRARIES should not be necessary for removing libtool. #! /bin/sh # Make sure libtool is removed. # Report from Kevin Dalley . $srcdir/defs || exit 1 cat >> configure.in << 'END' AC_LIBTOOL_DLOPEN AC_DISABLE_SHARED AC_PROG_LIBTOOL AC_SUBST(LIBTOOL_DEPS) END : > ltmain.sh : > config.guess : > config.sub $ACLOCAL || exit 1 $AUTOMAKE || exit 1 Tom Tromey <[EMAIL PROTECTED]> writes: > >>>>> "Kevin" == Kevin Dalley <[EMAIL PROTECTED]> writes: > > Kevin> In a Makefile which is created using automake-1.4f, libtool is not > Kevin> removed by distclean-am, in fact, it doesn't seem to be removed at > Kevin> all. In automake-1.4-p4, libtool is removed by distclean-am. These > Kevin> are the libtool related macros which I use: > > Kevin> AC_LIBTOOL_DLOPEN > Kevin> AC_DISABLE_SHARED > Kevin> AC_PROG_LIBTOOL > Kevin> AC_SUBST(LIBTOOL_DEPS) > > Can you tell me more about this bug? > I don't see it. > > Run the appended test. Then look at the resulting Makefile.in. It > shows that distclean depends on distclean-am, which depends on > distclean-libtool, which does `rm -f libtool'. > > How can I modify this test to see the bug? > > Tom > > #! /bin/sh > > # Make sure libtool is removed. > # Report from Kevin Dalley > > . $srcdir/defs || exit 1 > > cat >> configure.in << 'END' > AC_LIBTOOL_DLOPEN > AC_DISABLE_SHARED > AC_PROG_LIBTOOL > AC_SUBST(LIBTOOL_DEPS) > END > > cat > Makefile.am << 'END' > lib_LTLIBRARIES = libfoo.la > libfoo_la_SOURCES = foo.c > END > > : > ltmain.sh > : > config.guess > : > config.sub > > $ACLOCAL || exit 1 > $AUTOMAKE || exit 1 > -- Kevin Dalley [EMAIL PROTECTED]
