Emerging gzip-1.3.5-r1 under amd64 causes this error message: configure.in:24: version mismatch. This is Automake 1.8.3, configure.in:24: but the definition used by this AM_INIT_AUTOMAKE configure.in:24: comes from Automake 1.8.5. You should recreate configure.in:24: aclocal.m4 with aclocal and run automake again. make: *** [Makefile.in] Error 1 Adding the lines aclocal autoheader automake autoconf to src_unpack() under /usr/portage/app-arch/gzip/gzip-1.3.5-r1.ebuild corrected the problem. This package evidently should depend on automake >=1.8.5. Reproducible: Always Steps to Reproduce: 1. ACCEPT_KEYWORDS="~amd64" emerge --ask gzip Actual Results: It bombed out with the error message configure.in:24: version mismatch. This is Automake 1.8.3, configure.in:24: but the definition used by this AM_INIT_AUTOMAKE configure.in:24: comes from Automake 1.8.5. You should recreate configure.in:24: aclocal.m4 with aclocal and run automake again. make: *** [Makefile.in] Error 1 Expected Results: It should have compiled and emerged properly. Portage 2.0.50-r8 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.2-r9, 2.6.4-gentoo-r1) ================================================================= System uname: 2.6.4-gentoo-r1 x86_64 5 Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://ftp.ndlug.nd.edu/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib alsa amd64 apm arts avi berkdb cdr crypt cups encode esd foomaticdb gdbm ggi gif gnome gpm gtk gtk2 guile imlib jpeg kde libg++ libwww mikmod motif mozilla mpeg multilib mysql ncurses nls nogcj oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline scanner sdl slang spell ssl tcltk tcpd truetype usb xml2 xmms xv zlib"
autoreconf would be a better command to issue- invokes aclocal, autoconf, automake, autoheader, auto-blah as needed. What is a wee bit odd about this, is that autoconf shouldn't be invoked in anyway exposing the automake version differences. Any clue how/why autoconf is getting called? Looking through the ebuild, configure.in isn't being touched at any point (so unless your system clock is way off and configure's timestamp is updated, autoconf shouldn't be running).
Just as a FYI.... This bug also applies to i386 hardware as well. Once I emerged automake ... gzip was able to build and install successfully. - Ryan
I can confirm this problem. Once I updated automake from 1.8.3 to 1.8.5-r1, I could then update gzip.
so the testing version of gzip requires an automake also in testing? removing amd64 from harware since this isnt an amd64 bug.
Unless somebody else has a real interest in this, I'm going to hack up the debian patch we use so that we're not applying the original author's configure/makefile additions. they basically upgraded the automake version, and there isn't any reason to. Thoughts/takers?
go brian go
rebuilt the patch; should have anymore problems (automake-1.8.5 is in stable now anyways though ...)
