Setting up a new gentoo system, 'emerge --emptytree system' stops with ------------------- cd /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4 && autoconf ac-wrapper: /usr/bin/autoconf-2.13 is missing or not executable. Please try emerging the correct version of autoconf. make: *** [/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/configure] Error 1 creating lib-src/Makefile creating src/Makefile cd /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4 && autoconf ac-wrapper: /usr/bin/autoconf-2.13 is missing or not executable. Please try emerging the correct version of autoconf. make: *** [/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/configure] Fehler 1 !!! ERROR: app-editors/emacs-21.4-r1 failed. !!! Function src_compile, Line 107, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ------------------- I solved this with: ------------------- # unmerge autoconf # emerge =autoconf-2.13 # emerge emacs ------------------- emerge emacs caused autoconf-2.59-r6 to be emerged again, in addition to 2.13. It is a nasty workaround as I cannot do an 'emerge --resume' anymore and 'emerge --emptytree system' merges soo many packages merged before ... Reproducible: Always Steps to Reproduce: 1. set up a gentoo stage 2 system 2. emerge --emptytree system Actual Results: Most packages get merged, some errors (not related to emacs and/or autoconf) which I could find workarounds for, the emerge stops as described above. 'emerge --emptytree system' also stopped as described in Bug 110213, which was caused by a circular dependency emacs was involved in. You can also see an output of 'emerge info' there I got before merging =autoconf-2.13. Output of 'emerge info' after merging =autoconf-2.13 see below. ================== My first try to solve the problem was to merge not emacs-21.4-r1 but emacs-21.4. To do this I had to unmerge media-libs/giflib: ------------------ # emerge --pretend emacs These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] media-libs/giflib (is blocking media-libs/libungif-4.1.3) [ebuild N ] media-libs/libungif-4.1.3 [ebuild N ] app-editors/emacs-21.4 ------------------ But emerging emacs-21.4 faild the same way emacs-21.4-r1 failed. So I got back to the r1-release which caused giflib to be emerged again. Now I have installed giflib-4.1.3 as well as libungif-4.1.3. Wonder why giflib blocks libungif but gifunlib does not block giflib ... ================== emerge info (after having merged autoconf-2.13 manually and 'emerge emacs'): Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.9-gentoo-r9Gentoo_Kernel_2.6 i686) ================================================================= System uname: 2.6.9-gentoo-r9Gentoo_Kernel_2.6 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mir.zyrianes.net/gentoo/ ftp://ftp.linux.ee/pub/gentoo/distfiles/" LANG="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi aim alsa apache2 apm audiofile avi bash-completion bcmath berkdb bitmap-fonts bluetooth bzip2 cdparanoia cdr cpdflib crypt cups dga directfb divx4linux dvb dvd dvdr dvdread eds emacs emboss encode exif famfbcon ffmpeg flac foomaticdb fortran ftp gdbm gif ginac gnome gphoto2 gpm gstreamer gtk gtk2 hal icq ieee1394 imagemagick imap imlib ipv6 jabbar jack java javascript jpeg kde ladcca leim libg++ libwww lirc lm_sensors mad memlimitmikmod mime ming mmx mng motif mozilla mp3 mpeg msn mule nas ncurses nls ogg oggvorbis opengl oscar pam pdflib perl php plotutils png posix python qt quicktime readline samba scanner sdl session shorten skey slang sndfile socketsspeex spell spl sse ssl svg svga symlink sysvipc szip tcltk tcpd tetex theora tidy tiff truetype truetype-fonts type1-fonts udev unicode usb v4l vcd vorbis win32codecs wmf xine xml xml2 xosd xpm xprint xv xvid yahoo zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
>Setting up a new gentoo system, 'emerge --emptytree system' stops with What's the base? Stage 1,2,3? You shuld have auto{conf,make}-wrapper installed, which depend on all respective autotool versions. giflib/ugif is another topic, see Bug 85720
It is a stage 1 installation. This is from 'emerge search ...' (after having installed autoconf-2.13 and emacs as described above): ------------------- * sys-devel/autoconf-wrapper Latest version available: 3-r1 Latest version installed: 3-r1 Size of downloaded files: 0 kB Homepage: http://www.gentoo.org/ Description: wrapper for autoconf to manage multiple autoconf versions License: GPL-2 * sys-devel/automake-wrapper Latest version available: 1-r1 Latest version installed: 1-r1 Size of downloaded files: 0 kB Homepage: http://www.gentoo.org/ Description: wrapper for automake to manage multiple automake versions License: GPL-2 ------------------- Well ... 'Size of downloaded files' seems a little small to me ...
How exactly did you get "emacs" into "system"? The main problem is that any stage *prior* to a completed stage3 is an incomplete system. You cannot possibly expect every package to work with a system that is only bootstrapped. This is even more evident as only certain USE flags are honored during bootstrap, for QA reasons.
Don't know how I got these packages into 'system'. Detailed description of my installation: I am running an about 18 month old gentoo installation. As this installation was originally based on an 2.4-kernel and I now use 2.6, as I have changed lots of hardware and as I merged and unmerged a lot of packages, I want to make a brand new start. I did the installation form the running gentoo system in a root terminal. I did follow the steps described in the 'Gentoo Linux x86 Handbook', chapter 'Installing Gentoo' and did an stage 1 installation. Everything works fine until 'emerge --emptytree system'. This stopped first claiming about aspell (see Bug 110213). I did '# USE="-gpm" emerge --resume', waited until aspell was emerged, stopped the emerge with STRG+C, then did '# emerge --resume' so that gpm-useflag was set again. I did it similar when emerge failed to merge dev-util/dialog with the unicode-useflag. I also got trouble with sys-apps/hal and later with media-libs/svgalib as I descibed in Bug 110383. Doing an 'emerge gentoo-sources' broke the possibility of doing 'emerge --resume' to continue emerging the system, so I added 'app-text/aspell -gpm' and 'dev-util/dialog -unicode' to /etc/portage/packages.use and called again 'emerge --emptytree system'. Then it stopped at emerging emacs. (Hope I did not forget anything...) As there is so much trouble with emerging the system with my (obviously) problematic useflag-combination, I wonder if using the standard useflags to set up the system and afterwards set the useflags as I want them and do an 'emerge --newuse' would not be the better way ... ?
It would defintely be less problematic. Release Engineering recommends that all users perform a stage3 installation, then make their customizations, as it *always* produces a working system. As more and more USE flags are introduced, it is essentially impossible for us to guarantee that stages 1 and 2 work with anything other than the defaults for each architecture.
I see. Would it then not be the best to write this recommendation of using standard useflags into the 'Gentoo Linux x86 Handbook'? The handbook handles usefalgs just before bootstrapping, so I got the impression that useflags should be set then. I would definitely prefer setting up a system and afterwards compile some packages again (via 'emerge --newuse') than having all this trouble I had in setup ... and I think most other users would, too ... Would you agree that it would be an useful proposal to change the handbook the mentioned way? Should I email this to one of the handbook authors? I will now mkfs and start the gentoo installation again, this time with standard useflags. Thanks so far.
Don't do anything, actually, as I've already recommended this to the Docs Team via a bug and they've made changes in the Handbook already. Unfortunately, many users still use the stage1 method, and I'm currently working on a discussion how to curb this problem. At any rate, emacs should have pulled in all of its dependencies properly, so I'm going to assign this to the emacs maintainers.
Could someone summarize the problem please? Emacs should depend on =autoconf-2.13? or autoconf-wrapper? I always work off stage3 and need some hints here.
(In reply to comment #8) > Could someone summarize the problem please? Emacs should depend on > =autoconf-2.13? or autoconf-wrapper? > > I always work off stage3 and need some hints here. Anyone?
I close this, stage3 is recommend anyway for installation and this bug is just stale.