sys-devel/gcc-4.8.3 fails to build. I tried both with CFLAGS="-O2 -march=generic -pipe" and with CFLAGS="-O2 -march=native -pipe". You'll find the build log in attachment.
Created attachment 379024 [details] gcc-build-logs.tar.bz2
Same here
Well, yeah, -march=generic isn't a valid option. Can I get your logs with -march=native?
Comment on attachment 379024 [details] gcc-build-logs.tar.bz2 Wrong builds log.
Created attachment 379062 [details] GCC build logs, compressed.
Uploaded a new builds log, corresponding to a failed build with CFLAGS="-O2 -march=native -pipe".
The error you're getting is: /usr/include/cairo/cairo-features.h:13:3: error: #error "abi_x86_32 not supported by the package."
Why did we enable multilib java again? You can probably work around this for now by disabling USE=awt, or USE=gcj.
I had the same error. A solution / workaround is to reinstall x11-libs/cairo. multilib-build.eclass contains a workaround: $ cvs log -r1.47 multilib-build.eclass RCS file: /var/cvsroot/gentoo-x86/eclass/multilib-build.eclass,v Working file: multilib-build.eclass head: 1.56 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 56; selected revisions: 1 description: ---------------------------- revision 1.47 date: 2014-05-07 19:33:49 +0200; author: mgorny; state: Exp; lines: +9 -1; commitid: 3a6a536a6e7c4567; Use amd64 headers for i686 when USE=-abi_x86_32 to maintain compatibility with current state of emul-linux. Fixes bug #509556. $ cvs di -r1.{46,47} multilib-build.eclass Index: multilib-build.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/multilib-build.eclass,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- multilib-build.eclass 1 May 2014 09:52:27 -0000 1.46 +++ multilib-build.eclass 7 May 2014 17:33:49 -0000 1.47 @@ -1,6 +1,6 @@ # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/eclass/multilib-build.eclass,v 1.46 2014/05/01 09:52:27 mgorny Exp $ +# $Header: /var/cvsroot/gentoo-x86/eclass/multilib-build.eclass,v 1.47 2014/05/07 17:33:49 mgorny Exp $ # @ECLASS: multilib-build.eclass # @MAINTAINER: @@ -454,6 +454,14 @@ # Note: match a space afterwards to avoid collision potential. sed -e "/${abi_flag} /s&error.*&include <${CHOST}${f}>&" \ -i "${ED}/tmp/multilib-include${f}" || die + + # Hack for emul-linux-x86 compatibility. + # It assumes amd64 will come after x86, and will use amd64 + # headers if no specific x86 headers were installed. + if [[ ${ABI} == amd64 ]]; then + sed -e "/abi_x86_32 /s&error.*&include <${CHOST}${f}>&" \ + -i "${ED}/tmp/multilib-include${f}" || die + fi fi done fi
(In reply to Ryan Hill from comment #8) > Why did we enable multilib java again? > > You can probably work around this for now by disabling USE=awt, or USE=gcj. Same problem with gcc-4.7.3-r1. I cannot disble these USE flags, because I need them.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #9) > I had the same error. > A solution / workaround is to reinstall x11-libs/cairo. I really don't understand how rebuilding cairo could fix gcc compilation, but I'll try...
(In reply to Ivan Iraci from comment #11) Rebuilding of x11-libs/cairo will change content of /usr/include/cairo/cairo-features.h, which is a wrapper header generated by multilib-build.eclass.
(In reply to Ivan Iraci from comment #10) > > You can probably work around this for now by disabling USE=awt, or USE=gcj. > I cannot disble these USE flags, because I need them. USE="-awt -gcj" works as a temporary workaround, I can confirm it.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > Rebuilding of x11-libs/cairo will change content of > /usr/include/cairo/cairo-features.h, which is a wrapper header generated by > multilib-build.eclass. I recompiled cairo, but I have no time to rebuild gcc at the moment. I'll try it out in the next days.
rebuilding cairo fixed the error for me
bad header generation by an eclass that breaks packages that use those libs isn't the fault of the breaking package i'm guessing this is a dupe, so assigning to the multilib peeps to close out
*** This bug has been marked as a duplicate of bug 509556 ***
