Bringing a new system up with 2004.3 stage2 and portage-20041022.tar.bz2, 'emerge system' fails in automake-1.8.5 because it needs autoconf >= 2.58. 'emerge autoconf' first tries to build the automake-1.8.5 (which of course, still fails). The fix required a manual build/install of autoconf-2.59 (--prefix=/usr/local) and then the 'emerge system' completed successfully. Reproducible: Always Steps to Reproduce: 1. Install 2004.3 stage2 and portage-20041022.tar.bz2. 2. emerge system 3. Actual Results: automake was package 8 of 50 in In automake's ./configure, it aborted saying it needed autoconf >= 2.58. Expected Results: It should build and install autoconf >= 2.58 before automake-1.8.x. Knoppix / # emerge info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.27 i686) ================================================================= System uname: 2.4.27 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://gentoo.ccccom.com http://open-systems.ufl.edu/mirrors/gentoo ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acpi apm arts avi berkdb bitmap-fonts crypt cups directfb encode f77 fam fbcon foomaticdb fortran freetds gdbm gif gpm gtk2 imlib java jpeg kde ldap libg++ libwww mad maildir mikmod milter mmx motif mpeg mysql ncurses nls odbc oggvorbis opengl oss pam pdflib perl png python quicktime readline samba sdl snmp spell sse ssl svga tcpd truetype usb x86 xml2 xmms xv zlib"
I forgot to mention that I did do an 'emerge sync' at 5:00 PM 11/15/04 and again at 7:00 AM 11/16/04 (today), so it doesn't appear to be the contents of the portage snapshot that's causing me the problems.
A workaround I used was to install autoconfig manually by doing emerge --fetchonly autoconf cp /mnt/gentoo/usr/portage/distfiles/autoconf-2.59.tar.bz2 /tmp cd /tmp tar jxfv autoconf-2.59.tar.bz2 cd autoconf-2.59 ./configure make make install
Just had the same problem trying to install Gentoo from the latest stage2. Sniper's workaround of manually compiling autoconf-2.59 worked.
I have the same problem, installing from stage2-x86-2004.3.tar.bz2. During 'emerge system' the build of automake-1.8.5-r1 fails because autoconf-2.58 or better is needed. Trying to emerge autoconf manually gives: > Knoppix / # emerge -a autoconf > > These are the packages that I would merge, in order: > > Calculating dependencies ...done! > [ebuild N ] sys-devel/automake-1.8.5-r1 > [ebuild N ] sys-devel/libtool-1.5.2-r7 > [ebuild N ] sys-devel/m4-1.4.1 > [ebuild N ] sys-devel/autoconf-2.59-r5 Which obviously isn't going to work since the build of automake will fail. However emerging libtool gives: > Knoppix / # emerge -a libtool > > These are the packages that I would merge, in order: > > Calculating dependencies ...done! > [ebuild N ] sys-devel/m4-1.4.1 > [ebuild N ] sys-devel/autoconf-2.59-r5 > [ebuild N ] sys-devel/automake-1.8.5-r1 > [ebuild N ] sys-devel/libtool-1.5.2-r7 So now autoconf is built before automake and all is well. It is weird though, since the automake ebuild does list '>=sys-devel/autoconf-2.58' as a DEPEND. Hope this helps :).
Doing my frist gentoo install I had this problem as well I was able to do an emerge -u automake at ~10am EST time and resolve my problem and resume my emerge system.
I ran into the same problem, but I was able to continue by doing an emerge autoconf --nodeps then continuing to emerge sysem (I built stage2 x86 on Nov 28 04)
automake was still using old WANT_AUTOCONF syntax for some reason
Autoconf is installed _after_ automake,which requires autoconf. This order needs to be fixed. Installing autoconf in /usr/local emerge automake and uninstall afterwards works,as mentioned below. Gentoo 2004/3
I don
I don´t know why is this marked as FIXED. I have just experienced the same problem with fresh 2004.3 stage 2 install, emerge synced about 3 hours ago. *confused*
my last sync was about 10-15 hours ago, but the problem persists. I'm using the workaround "emerge -a libtool", which is actually running. As SpanKY noticed in comment#7 automake still uses sth. like WANT_AUTOCONF -- but - did SpanKY provide a patch? - did SpanKY commit some changes into the "stable"(?) tree? Could someone correct this, please?
I would like to point out that this bug actually means that standard Gentoo install FAILS. This is really a bad thing for new Gentoo users and for reputation of this otherwise great distro. :-( Therefore someone should reopen this bug and raise the priority to critical at least, to be honest. And NOT to mark bugs as fixed/duplicate etc., when they are not. This is commonplace for Mozilla Bugzilla, but I really hope that this will not happen with Gentoo. Peace.
Why is this bug marked as resolved/fixed? I tried to install yesterday with yesterdays portage snapshot and stage2 athlon-xp, same problem as described here, had to use workaround. Workaround found on bugzilla for fresh Gentoo install = fixed? Yay.
Spanky, can you be a little more verbose and explain why this was closed/how it was fixed?
New system with 2004.3 stage2 and portage-20041206.tar.bz2, Emerge system fails in automake because it needs autoconf. Emerge autoconf first tries to build automake. 1. Install 2004.3 stage2 and portage-20041206.tar.bz2. 2. emerge system It should build and install autoconf before automake. livecd / # emerge --info Portage 2.0.51-r2 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.7-gentoo-r11 i686) ================================================================= System uname: 2.6.7-gentoo-r11 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium2 -pipe -O2" CHOST="i386-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium2 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb bitmap-fonts crypt cups encode f77 foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib jpeg kde libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd truetype x86 xml2 xmms xv zlib"
since i tweaked automake/autoconf, ive tested the following KEYWORDS: ~amd64 / amd64 / ~ia64 / ia64 / x86 and the following 2004.3 stages: amd64-stage{2,3} ia64-stage{2,3} x86-stage2 each time all i did was extract the tarball, emerge sync, run bootstrap (if stage 2), and then emerge system none of them failed i have yet to encounter the bug mentioned here ... matter resolved for me
Here's my experience of the problem and how I solved it Automake-1.8.5-r1 wouldn't be install because the system required autoconf => 2.58. Now I did emerge -O autoconf and the problem persited. I finally solved my problem by emerge autoconf-wrapper and that solved my problem. I'm still a noob to Gentoo. Hope what I posted may shed light on how to solve this problem.
that has nothing to do with this bug because auto{make,conf}-wrapper's are only in unstable ... people here say they're all running stable
vapier, it failed for me on multiple machines using the following make.conf settings: CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" USE="-X -qt -gnome -gtk -cups acpi berkdb crypt directfb fam fbcon freetds ipv6 java ldap libwww maildir mmx mysql odbc pam perl samba snmp ssl sse spell truety pe usb xml2 zlib x86 milter -ipv6" Maybe using my USE variable will provide you with different results when you do an emerge system. IIRC, it might also fail if you do an emerge perl, but I may be remembering a different system and different set of problems.
ive fixed up diffutils and m4 since they were causing circular dependencies the `emerge system -p` with the provided USE setup now has this snippet: <snip> [ebuild N ] sys-devel/autoconf-2.59-r5 [ebuild N ] net-misc/iputils-021109-r3 [ebuild N ] dev-libs/popt-1.7-r1 [ebuild N ] net-misc/rsync-2.6.0-r3 [ebuild N ] net-misc/wget-1.9-r2 [ebuild N ] sys-apps/help2man-1.29 [ebuild N ] sys-devel/automake-1.8.5-r1 [ebuild N ] sys-apps/coreutils-5.2.1 <snip>
This bug is still causing problems, albeit in a different way. I'm doing a customized set of stage tarballs in preparation for making a livecd (using catalyst) and this problem seems to persist. I had to halt the process and take care of it myself. Why not make autoconf-1.8.5 depend on autoconf-wrapper? I know it sounds strange, but it does fix the problem. And I know this technically isn't supported, but this really should be done for the sake of completeness, not to mention sanity.
(In reply to comment #20) > This bug is still causing problems, albeit in a different way. I'm doing a > customized set of stage tarballs in preparation for making a livecd (using > catalyst) and this problem seems to persist. I had to halt the process and take > care of it myself. > > Why not make autoconf-1.8.5 depend on autoconf-wrapper? I know it sounds > strange, but it does fix the problem. And I know this technically isn't > supported, but this really should be done for the sake of completeness, not to > mention sanity. > Woopsie. I was trying to say that automake-1.8.5 should depend on autoconf-wrapper. Darn. And it was so eloquent, too...
