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 for x86_64-pc-linux-gnu-strip... no checking for strip... strip checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-pc-linux-gnu-gcc... getCC -fno-pic -nopie checking for x86_64-pc-linux-gnu-gcc... (cached) getCC -fno-pic -nopie checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. !!! ERROR: sys-boot/grub-0.95.20040823 failed. !!! Function econf, Line 447, Exitcode 77 Portage 2.0.51-r8 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-rc2-mm3 x86_64) ================================================================= System uname: 2.6.10-rc2-mm3 x86_64 Mobile AMD Athlon(tm) 64 Processor 3400+ Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Oct 28 2004, 08:02:56)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=x86-64 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=x86-64 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://gentoo.osuosl.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi aim alsa arts audiofile avi berkdb bitmap-fonts bzlib caps cdr crypt cups dga dio dvd dvdr encode esd ethereal exif f77 fam fftw flac flash flatfile fortran ftp gif gnome gphoto2 gpm gps gtk gtk2 gtkhtml imap imlib inifile ipv6 jabber jack java jikes jp2 jpeg junit kde libedit lzw lzw-tiff mad maildir mikmod mime ming mmap mng mozilla mpeg mpi msn multilib ncurses nls offensive oggvorbis openal opengl oss pam pcmcia pcre pdflib perl pic pie png pnp portaudio posix ppds python qt quicktime readline samba scanner sdl session shared sharedmem slang sndfile sockets socks5 spell ssl szip tcktk tcpd theora tiff truetype unicode usb userlocales wmf xine xml xml2 xmms xpm xrandr xv xvid zlib" Reproducible: Always Steps to Reproduce: 1. Fix missing WANT_AUTOMAKE=1.8 for aclocal in /usr/portage/sys-boot/grub/grub-0.95.20040823.ebuild 2. Try to emerge -u world (or emerge grub) 3. Watch emerge fail. Actual Results:
attach the config.log from the build directory
Ok vapier, please re-open this. This is most certainly a legitimate bug against gcc. Adding multilib support to Makefile in /var/tmp/portage/gcc-3.4.3-r1/work/gcc-3.4.3/libstdc++-v3 multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /var/tmp/portage/gcc-3.4.3-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3 Running configure in multilib subdir 32 pwd: /var/tmp/portage/gcc-3.4.3-r1/work/build/x86_64-pc-linux-gnu mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-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 for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/gcc-3.4.3-r1/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.3-r1/work/build/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [configure-target-libstdc++-v3] Error 1 Scott ~ # emerge info Portage 2.0.51-r8 (default-linux/amd64/2004.3, gcc-3.4.1, glibc-2.3.4.20041102-r0, 2.6.10-rc2 x86_64) ================================================================= System uname: 2.6.10-rc2 x86_64 AMD Opteron(tm) Processor 148 Gentoo Base System version 1.6.6 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jul 10 2004, 15:15:38)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-fPIC -mtune=opteron -march=opteron -O2 -g -pipe " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-fPIC -mtune=opteron -march=opteron -O2 -g -pipe " DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks keepwork" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="GAPING_SECURITY_HOLE X X509 Xaw3d a52 aac acpi acpi4linux alsa amd64 arts artswrappersuid artworkextra atm audiofile avantgo bluetooth caps cddb cdf cdparanoia cdr chroot cle266 codecs crypt css cups devfs26 dga dio distcache divx4linux djbfft dnd dts dv dvb dvd dvdr dvdread erandom esd exif extensions f77 faac faad fam fame fax ffmpeg flac flash flexresp fmod font-server fortran freetts freetype gdbm geoip gif gimp gimpprint glade glgd glut gmail gmp gnokii gphoto2 gpm gps graphviz gs gsl gstreamer gtk gtk2 gtkhtml icq idea ieee1394 imagemagick imap imlib imlib2 ipv6 irda irmc jabber jack jack-tmpfs java javascript jbig jp2 jpeg jpeg2k junit kadu-modules kadu-voice kde koffice-plugin lcms libgd libgda libsamplerate libwww lirc live ltsp lzw lzw-tiff mad mbox mbrola mcal md5sum memlimit mhash mikmod ming mixer mjpeg mmap mng mnogosearch monkey motif mozcalendar mozilla mozp3p mozsvg mp3 mpeg mpeg4 mpi mplayer msdav msn multilib multitarget nagios-dns nagios-ntp nagios-ping nagios-ssh nasncurses nls nopri nozaptel nptl nptlonly ntlm nvidia nviz oav odbc offensive ofx oggvorbis openal opengl operanom2 oscar oss pam parse-clocks pcap pcntl pcre pda pdflib perl pg-vacuumdelay php pic pie plotutils png pnp portaudio posix postgres ppds pthreads python readline real recode remote samba scanner sdl serial shared sharedmem slang slp sndfile snmp snortsam soap sockets socks5 speedo speex spl ssl stats svg t1lib tcpd tidy tiff timidity tokenizer transcode transparent-proxy truetype truetype-fonts type1 type1-fonts usb userlocales uudeview v4l v4l2 vcd wifi wmf xgetdefault xinerama xml2 xmlrpc xmms xosd xpm xprint xrandr xscreensaver xv xvid xvmc yahoo yaz yv12 zlib zvbi"
Created attachment 45827 [details] m32 config.log /var/tmp/portage/gcc-3.4.3-r1/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/config.log
Created attachment 45828 [details] m64 config.log /var/tmp/portage/gcc-3.4.3-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/config.log
This is an recurring issue with gcc on amd64, lv keeps fixing it or finding workarounds and someone keeps breaking it.
reopening per users request
The first emerge info you gave had an invalid CFLAG (-march=x86-64) which will cause this error. As for the second emerge info, things look better, but what happens if you have no CFLAGS at all?
My CFLAGS don't have that error. 'CFLAGS="" emerge gcc' doesn't change anything.
I needed to rebuild my kernel to let this work. After that it worked like a charm. Needed options: CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y
I can second this. Same problem happened to me yesterday while I was doing a fresh 2004.3 install (stage 3 to save some time because later on everything is recompiled anyway due to the profile update) and upgrading that to 2005.0 which went smooth until I hit that problem. I was unable to recompile gcc at all due to this. It is strange though that when configure checks for a working gcc by compiling a short test program, the resulting executable is in aout instead of elf. So this seems to be a problem with the latest incarnation of gcc (3.4.3.20050110) in portage because for this check the compiled gcc is used (which is correct) and not the system wide gcc which works fine. Has anyone any idea what's causing this? Could this result in bigger problems because per default, gcc should output elf binaries?
Just figured, this is a duplicate of bug #72379. There are several possible ways explained there to get around this bug, yet no real fix or explanation why this is happening in the first place.
this is user error not a gcc bug. from original bug report: CFLAGS="-march=x86-64 -pipe -O2" from gcc manpage: k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support. invalid CFLAGS will consistently get you this error. suggest closing b00g. ;)
Indeed, but future posting by Blu3 shows valid CFLAGs and same error. While the first post might have been contributed to by user malfunction, future follow up submissions show the same problem without any noticeable user errors :)
Yes, please .. stop closing bugs so quickly without really trying to find the root problem. :/ I finally fixed my installation but I'm not sure what exactly I did to fix it. I downloaded numerous binary packages to try and build from them, I changed flags left and right. In the end I feel it was related to the use of multi* USE flags with not just gcc, but the whole toolchain. Something got out of whack and it was darn difficult to fix. Mostly because we couldn't find anyone who was intimately familiar with the toolchain to actually look into the problem. And I also have to reiterate that I'm rather disappointed that some people have been so aggressive in trying to close this and other similar bugs as user error or lack of information when we have provided such. To those that have the powers and familiarity, I suggest studying the use of multi* flags with the toolchain. There are some misleading descriptions for USE flags that imply they are for other architectures only that can be/should be used for 64bit code, and there are some that -shouldn't- be used even though their description indicates they can. I apologize that I didn't keep detailed notes, but I was frustrated for several months and sorely fed up with everyone telling me it was user error and closing my bugs. Especially when I find the same bug on the gcc list and the people who -really- know are acknowledging it.
does the problem still persist, even after a USE="multilib" emerge gcc? otherwise we can close this one i guess
the use flag of multilib has nothing to do with the real problem(s). according to the multiple bugs filed related to these compiler phrases, there are multiple issues. feel free to close it but people aren't identifying all the real reasons. - multilib is a reason - multitarget is a reason - ia32 emul is a reason - cflags is a reason - circular dependancies is a reason and other reasons. in order to solve my problem, i had to copy binary builds from developers of my entire toolchain to jump versions. thus my problem was not solved, i simply avoided it. i have no problems recompiling now that i've done that. those with the means should make a Things to Try checklist. out of all these related bugs, 1/2 of the reporters have things fixed for them, the other 1/2 are still tearing their hair out.
*** Bug 72379 has been marked as a duplicate of this bug. ***
*** Bug 86122 has been marked as a duplicate of this bug. ***
New release (2005.0) doesn't have these problems and the user involved has said himself that he's fixed it through some means. There's plenty of things you can try which are documented here and in other bugs, last 'on topic' comment occurred over three weeks ago. Bug is closed as RESOLVED FIXED, anyone still experiencing problems should update to the new release - if you still get an error, open a bug.
