Hi Carlo, apparantly on my system "make" does randomly decide which of srclib/confuse/Makefile.am or srclib/confuse/Makefile.in is newer. This is depending on the "svn co" command.
If Makefile.in is "newer", the build succeeds. Otherwise I get the following problems (touching Makefile.am, to force the problem): [EMAIL PROTECTED] confuse]$ [EMAIL PROTECTED] confuse]$ touch Makefile.am [EMAIL PROTECTED] confuse]$ make cd . && /bin/sh /home/scratch/ganglia-svn/mc1/srclib/confuse/support/missing --run automake-1.9 --foreign configure.ac:8: version mismatch. This is Automake 1.9.5, configure.ac:8: but the definition used by this AM_INIT_AUTOMAKE configure.ac:8: comes from Automake 1.9.6. You should recreate configure.ac:8: aclocal.m4 with aclocal and run automake again. make: *** [Makefile.in] Error 1 [EMAIL PROTECTED] confuse]$ [EMAIL PROTECTED] confuse]$ [EMAIL PROTECTED] confuse]$ aclocal /usr/share/aclocal/linc.m4:1: warning: underquoted definition of AM_PATH_LINC run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/libole2.m4:18: warning: underquoted definition of AM_PATH_LIBOLE2 aclocal:configure.ac:19: warning: macro `AM_GNU_GETTEXT' not found in library aclocal:configure.ac:20: warning: macro `AM_GNU_GETTEXT_VERSION' not found in library aclocal:configure.ac:22: warning: macro `AM_PATH_CHECK' not found in library [EMAIL PROTECTED] confuse]$ [EMAIL PROTECTED] confuse]$ [EMAIL PROTECTED] confuse]$ automake [EMAIL PROTECTED] confuse]$ make cd . && /bin/sh /home/scratch/ganglia-svn/mc1/srclib/confuse/support/missing --run autoconf configure.ac:19: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:20: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION configure.ac:22: error: possibly undefined macro: AM_PATH_CHECK configure.ac:22: error: possibly undefined macro: AC_MSG_WARN configure.ac:56: error: possibly undefined macro: AC_CONFIG_LIBCONFIG_IN_STATIC configure.ac:57: error: possibly undefined macro: AC_CONFIG_LIBCONFIG_IN make: *** [configure] Error 1 So it seems we should not ship BOTH of Makefile.am and Makefile.in. If we ship Makefile.in, things seem to be OK. If we ship Makefile.am, we should fix building with older versions of Automake. As I said, relying on the latest-greatest release of the tools is not going to fly everywhere. As an alternative, "bootstrap" should touch "scrlib/comfuse/Makefile.in", similar to the make-distXX targets. Cheers Martin --- Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Fri, Jan 05, 2007 at 01:22:34AM -0800, Martin Knoblauch wrote: > > --- Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > > FWIW, I'd been doing `autoreconf --verbose --force --install` for > the > > > last > > > days with the FC6 provided autotool packages : > > > > > > autoconf 2.59 > > > automake 1.9.6 > > > libtool 1.5.22 > > > > > while I agree that we could start requiring some more recent > versions > > of the build tools, we should not be to ambitious. Apparently your > > recent checkins broke building on my pretty much yum-up-to-date FC4 > > system with the following tools: > > > > autoconf-2.59-5_11.rhfc4.at > > automake-1.9.5-1_24.rhfc4.at > > bison-2.0-6 > > flex-2.5.4a-41.fc4 > > libtool-1.5.20-4.99_14.rhfc4.at > > make-3.80-7 > > I indeed tested them in FC4 before committing them, and after your > report, run > a clean SVN checkout build in FC3 as well that was successfull. > > Indeed, in this case since I committed both the changes and the > generated > files then the dependency to the autotools being used was removed for > all > (most) use cases. > > For the bugs I was targeting though (2 bugs and 1 feature request), > the > configure script that was generated for libconfuse was broken > (probably > because it was generated with a newer version of the autotools which > was > originally used to do the rest) and i needed the source autotools > files > changed, and since libconfuse was using an even older version of the > tools > than the ones we are using for libmetrics and ganglia itself presumed > it was > probably left untouched since the original import. > > autoconf 2.59 > automake 1.8.5 > libtool 1.5.6 > > > Definitely your automake-1.9.6 rebasing causes grief on a SVN > build > > :-( > > > > make[3]: Entering directory > > `/home/scratch/ganglia-svn/ganglia-trunk/srclib/confuse' > > cd . && /bin/sh > > /scratch/ganglia-svn/ganglia-trunk/srclib/confuse/support/missing > --run > > automake-1.9 --foreign > > configure.ac:8: version mismatch. This is Automake 1.9.5, > > configure.ac:8: but the definition used by this AM_INIT_AUTOMAKE > > configure.ac:8: comes from Automake 1.9.6. You should recreate > > configure.ac:8: aclocal.m4 with aclocal and run automake again. > > make[3]: *** [Makefile.in] Error 1 > > make[3]: Leaving directory > > `/home/scratch/ganglia-svn/ganglia-trunk/srclib/confuse' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory > > `/home/scratch/ganglia-svn/ganglia-trunk/srclib' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > `/home/scratch/ganglia-svn/ganglia-trunk' > > make: *** [all] Error 2 > > I was unable to reproduce this problem, which IMHO should only happen > if the > Makefile.am file is for some reason found to be newer than the > generated > files (Makefile.in and Makefile), triggering automake to be invoked > again > or if you are changing Makefile.am > > in that case, just running aclocal and automake with the version of > the tools I had in my FC3 workstation "fixed" the problem as well, > and it is > anyway needed if Makefile.am was changed so that the changes are > applied. > > I agree with you though that we should better come up with a version > that is > well supported for all development environments (*), and I presume > that the > current de-facto is FC4? > > Carlo > > (*) I can't build ganglia in my Gentoo Linux 2006.1 main development > box > because of the libtool differences for example which is why I'd been > resorting > to use a FC6 VM for those builds after deducing that the autotools > used were > most likely for some version of Fedora/RedHat as they didn't match > either the > vanilla sources from Cygnus. > > ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
