The bug is reproducible and happens when trying to "emerge kde". I'm using altivec option and ACCEPT_KEYWORD="~ppc" in my make.conf The compiling fails only under "double" part of fftw source. Below the output of emerge command: * econf: updating fftw-3.1.1-double/config.guess with /usr/share/gnuconfig/config.guess * econf: updating fftw-3.1.1-double/config.sub with /usr/share/gnuconfig/config.sub * econf: updating fftw-3.1.1-single/config.guess with /usr/share/gnuconfig/config.guess * econf: updating fftw-3.1.1-single/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --host=powerpc-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-shared --enable-threads --enable-altivec --build=powerpc-unknown-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... powerpc-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu configure: error: requested SIMD type does not match selected precision !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/fftw-3.1.1/work/fftw-3.1.1-double/config.log !!! ERROR: sci-libs/fftw-3.1.1 failed. Call stack: ebuild.sh, line 1525: Called dyn_compile ebuild.sh, line 928: Called src_compile fftw-3.1.1.ebuild, line 62: Called econf '--enable-shared' '--enable-threads' '--enable-altivec' ebuild.sh, line 526: Called die And this is the emerge --info output: Portage 2.1_pre9-r4 (default-linux/ppc/ppc32/2006.0/G4, gcc-3.4.6, glibc-2.3.6-r3, 2.6.15-gentoo-r5 ppc) ================================================================= System uname: 2.6.15-gentoo-r5 ppc 7450, altivec supported Gentoo Base System version 1.12.0_pre18 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc X alsa altivec apache2 apm arts berkdb bitmap-fonts bonobo cdr cli crypt cups dri dvd eds emboss encode esd foomaticdb fortran gdbm gif gpm gstreamer gtk2 gtkhtml imlib ipv6 isdnlog jpeg kde ldap libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls nptl ogg opengl pam pcre pdflib perl png pppd python qt quicktime readline reflection ruby sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode vorbis xml xmms xorg xv zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
I noticed in double/simd/simd-altivec.h file, the following statement: #ifndef FFTW_SINGLE #error "ALTIVEC only works only in single precision" #endif so i modified the ebuild file to force the single precision even in the "double" case with --enable-float flag, in this way: elif use altivec; then myconfdouble="$myconfdouble --enable-float" fi In this way the configure process doesn't fail, but I'm not sure this is the correct way to fix the problem.
No, that fix is not correct. The correct fix is to not use altivec for double or higher precision. I've fixed this in the tree now.