Summary: | automake-1.8.5 fails to build because needs autoconf >= 2.58 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Todd Lyons <tlyons> |
Component: | [OLD] Development | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | greg_g, sniper |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Todd Lyons
2004-11-16 09:59:14 UTC
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... |