Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 ...)