I'm recompiling my system with new CFLAGS (I also switched from 2006.0 to 2006.1) which means that DirectFB is already installed. However, if I try to re-emerge it, I get the following error: $ emerge -pv DirectFB These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/DirectFB-0.9.24 USE="fbcon gif jpeg mmx mpeg png sdl sse truetype zlib -debug -fusion -static -sysfs" 0 kB Total size of downloads: 0 kB $ emerge DirectFB [...] Making all in generic make[4]: Entering directory `/var/tmp/portage/DirectFB-0.9.24/work/DirectFB-0.9.24/src/gfx/generic' /bin/sh ../../../libtool --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../lib -I../../../include -I../../../include -I../../../lib -I../../../src -D_REENTRANT -I/usr/include/libmpeg3 -fomit-frame-pointer -Wall -O2 -march=pentium4 -msse -msse2 -mmmx -mfpmath=sse -fno-omit-frame-pointer -pipe -D_GNU_SOURCE -Werror-implicit-function-declaration -c generic.c mkdir .libs i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../lib -I../../../include -I../../../include -I../../../lib -I../../../src -D_REENTRANT -I/usr/include/libmpeg3 -fomit-frame-pointer -Wall -O2 -march=pentium4 -msse -msse2 -mmmx -mfpmath=sse -fno-omit-frame-pointer -pipe -D_GNU_SOURCE -Werror-implicit-function-declaration -c generic.c -fPIC -DPIC -o .libs/generic.o generic_mmx.h: In function `Sop_argb_Sto_Dacc_MMX': generic_mmx.h:171: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make[4]: *** [generic.lo] Fehler 1 make[4]: Leaving directory `/var/tmp/portage/DirectFB-0.9.24/work/DirectFB-0.9.24/src/gfx/generic' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/var/tmp/portage/DirectFB-0.9.24/work/DirectFB-0.9.24/src/gfx' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/DirectFB-0.9.24/work/DirectFB-0.9.24/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/DirectFB-0.9.24/work/DirectFB-0.9.24' make: *** [all-recursive-am] Fehler 2 !!! ERROR: dev-libs/DirectFB-0.9.24 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile DirectFB-0.9.24.ebuild, line 100: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. $ emerge --info Portage 2.1.1 (default-linux/x86/2006.1, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.12.5 Last Sync: Fri, 15 Sep 2006 20:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] 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-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.4.3-r3, 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -msse -msse2 -mmmx -mfpmath=sse -fno-omit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -msse -msse2 -mmmx -mfpmath=sse -fno-omit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.inode.at/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="de_DE.utf8" LINGUAS="de el en" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalib acpi alsa arts audiofile bash-completion bitmap-fonts bluetooth bzip2 calendar cdparanoia cdr cli crypt cups dga dio directfb dlloader dri dvd dvdr dvdread elibc_glibc encode exif fam fbcon ffmpeg firebird firefox flac flatfile foomaticdb ftp gd gdbm gif gtk2 iconv icq ieee1394 imagemagick imap imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog java javascript jpeg jpeg2k kde kernel_linux ladspa libcaca libwww linguas_de linguas_el linguas_en lm_sensors maildir mbox mime mmap mmx mng motif mp3 mpeg ncurses nls nptl nptlonly nsplugin odbc offensive ogg openal opengl oscar pam pcre pda pdf perl plotutils png ppds pppd python qt3 qt4 quicktime readline real recode reflection scanner sdl session sharedmem slang sndfile sockets sox speex spell sse sse2 ssl startup-notification svg svga sysvipc tcpd tetex tidy tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l vcd video_cards_fbdev video_cards_nvidia video_cards_vesa videos vorbis win32codecs wmf wxwindows xface xinetd xml xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS $ cat /etc/make.conf | grep VIDEO_CARDS VIDEO_CARDS="nvidia vesa fbdev"
Should work w/ USE="-mmx"
I can confirm that $ USE="-mmx" emerge DirectFB works. However, I wonder why it compiled fine in the past, because I didn't change my use flags for a long time (especially "mmx" was always there). Is there any disadvantage of disabling mmx in DirectFB, i. e. does it run "slower" or "inefficient"? Is "USE=-mmx" rather a workaround than a fix?
i'm not going to review gcc-3.4 anymore ... see if it fails with gcc-4.1
