GCC 4.1[beta]

Message

curtis119 · Post by **curtis119** » Wed Nov 09, 2005 6:40 pm

I got a brand new laptop, compaq evo n610c, so I figured now would be a good time to try out gcc4. I started two days ago and used the most recent version, gcc-4.1.0-beta20051105. I started with a fresh 2005.1 stage3, emerged gcc4 first thing, recompiled my kernel and did emerge -e world. Everything except groff compiled perfectly. I emerged gnome next and ran into a problem with opensp and svgalib, both had to be compiled with gcc-3.3.6 (compiler that comes with stage3) but everything else has been clean so far. I haven't actually tried to run anything except the base system and emerging things so I have no idea if gnome is actually going to be useable or not. I'll post back when I'm finished.

ps If anyone has any ideas about groff, opensp or svgalib let me know.

Post by **Halcy0n** » Wed Nov 09, 2005 9:47 pm

curtis119 wrote:I got a brand new laptop, compaq evo n610c, so I figured now would be a good time to try out gcc4. I started two days ago and used the most recent version, gcc-4.1.0-beta20051105.

Don't know if you meant to use it, but gcc-4.1 is still really beta

gcc-4.0.2-r1 should be more sane. I haven't had time to look into the groff issue yet, but I know about it.

wrc1944 · Post by **wrc1944** » Wed Nov 09, 2005 9:55 pm

curtis199,
Don't know if it will help, but the three kde packages I had trouble with on my test machine went OK when I booted to a console login, su'd to root, and emerged wth no X running. Maybe your svgalib will emerge using the console login, and the others are worth a shot. IIRC, svgalib has to have the /usr/src linux symlink pointing to the current running kernel, in case your's isn't.

Just noticed you have 4.1.0 beta- guess I'm already out-of-date!
------------------------------------------------------------------------
To confirm:
I compiled a new kernel, and dmesg now reports gcc-4.0.2!

wrc@tux ~ $ dmesg
Linux version 2.6.14-archck3 (wrc@tux) (gcc version 4.0.2 (Gentoo 4.0.2-r1, pie-8.7.

) #1 PREEMPT Wed Nov 9 14:39:50 EST 2005

wrc@tux ~ $ su
Password:
tux wrc # emerge --info
Portage 2.0.53_rc7 (default-linux/x86/2005.1, gcc-4.0.2, glibc-2.3.6-r0, 2.6.14-archck3 i686)
=================================================================
System uname: 2.6.14-archck3 i686 AMD Athlon(tm) XP 1800+
Gentoo Base System version 1.12.0_pre9
dev-lang/python: 2.3.5, 2.4.2
sys-apps/sandbox: 1.2.13
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-r1
sys-devel/binutils: 2.16.1
sys-devel/libtool: 1.5.20-r1
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs"

curtis119 · Post by **curtis119** » Wed Nov 09, 2005 11:32 pm

Halcy0n wrote:
curtis119 wrote:I got a brand new laptop, compaq evo n610c, so I figured now would be a good time to try out gcc4. I started two days ago and used the most recent version, gcc-4.1.0-beta20051105.
Don't know if you meant to use it, but gcc-4.1 is still really beta gcc-4.0.2-r1 should be more sane. I haven't had time to look into the groff issue yet, but I know about it.

I meant to use it. I figured since I was going to do a fresh install anyway I may as well go for it and see what I could break.

If my system ends up really broken and unuseable I'll just switch it to gcc-3.4.4 and call it a day.

I only have 90 packages left on my "emerge gnome" and nothing else has failed to compile so 4.1 is doing pretty good so far. I'll post an update when it's finished.

wrc1944 wrote:curtis199,
svgalib has to have the /usr/src linux symlink pointing to the current running kernel, in case your's isn't.

The kernel was the first thing I compiled after I emerged gcc4 (and yes, my symlink is good) so it wasn't that.

thersites · Post by **thersites** » Thu Nov 10, 2005 1:00 am

curtis119, Halcy0n

my hack for compiling groff with the gcc-4.1 is to repeat the declarations from <??>.header in troff/input.cpp - at least the system doesn't crash when I read a man-page.
openssl breaks with -O1 - last time I tried it caused the irssi build to fail.
eix is the only package I have failing now with ...
../../src/portage/basicversion.h:90: error: extra qualification 'BasicVersion::' on member 'operator>='

How about another ebuild in portage? Release next week, isn't it?

curtis119 · Post by **curtis119** » Fri Nov 11, 2005 2:37 am

I finally finished my emerge gnome. Everything compiled cleanly except the following packages (I had to switch to gcc3.3.6 to get them to compile).

groff
opensp
aspell
svgalib
poppler

This is with binutils-2.16.91.0.3 and gcc-4.1.0_beta20051105. I already know that the binutils is the reason that svgalib wouldn't compile.

Tiger683 · Post by **Tiger683** » Fri Nov 11, 2005 7:43 am

curtis119 wrote:I finally finished my emerge gnome. Everything compiled cleanly except the following packages (I had to switch to gcc3.3.6 to get them to compile).

groff
opensp
aspell
svgalib
poppler

This is with binutils-2.16.91.0.3 and gcc-4.1.0_beta20051105. I already know that the binutils is the reason that svgalib wouldn't compile.

This is due to a change in gcc handling of c++ code, it now, as gcc page states, rejects ARM style friend injection.
at least groff (and probably others too) gets compiled, if you enable old behaviour with CXXFLAGS=${CFLAGS} -ffriend-injection.

I'm building my kernel before first reboot now, and all packages compiled with gcc-4.1 for now....

EDIT: build specs: glibc-2.3.6, binutils-2.6.91.0.3, gcc-4.1_beta20051105

EDIT2: at first time groff failed, i could also fix the first error (then i found out about -ffriend-injection) by preceding the offending block
(XXYYZZ not defined in this scope) with simple declaration "void XXYYZZ( void );"

EDIT3: i also changed the nptl_kernel_version in glibc ebuild to >=2.6.9 as i saw nxsty's overlay too late, but that's probably irrelevant for now

cheers

T

EDIT4: hmm, nasty typo, as if there were glibc 2.6.0

Tiger683 · Post by **Tiger683** » Sat Nov 12, 2005 5:21 pm

compilation of aspell with gcc-4.1_beta:

in /var/tmp/portage/aspell-0.60.4/work/aspell-0.60.4/modules/filter/nroff.cpp: line 76

change

Code: Select all

bool NroffFilter::process_char (FilterChar::Chr c);

to

Code: Select all

bool process_char (FilterChar::Chr c);

class qualifier inside class prototype definition is indeed bad idea

after that, do FEATURES="keepwork" emerge --resume, or someone should bake-up a patch....
cheers
T

wrc1944 · Post by **wrc1944** » Sun Nov 13, 2005 12:07 am

Hmmmmmm. nmbrthry's tests seem somewhat less than encouraging for any performance improvements, but I guess that will eventually come up with further tuning. I'm running gcc-4.02 for a few days now with no problems. I just synced and saw that gcc-4.1.0_beta20051112 is in portage- has anyone updated and have any feedback before I try it out?
4.0.2 is pretty reliable so far for me, at least on this test box that's just a generic kde desktop.

curtis119 · Post by **curtis119** » Sun Nov 13, 2005 12:19 am

wrc1944 wrote:Hmmmmmm. nmbrthry's tests seem somewhat less than encouraging for any performance improvements, but I guess that will eventually come up with further tuning. I'm running gcc-4.02 for a few days now with no problems. I just synced and saw that gcc-4.1.0_beta20051112 is in portage- has anyone updated and have any feedback before I try it out?
4.0.2 is pretty reliable so far for me, at least on this test box that's just a generic kde desktop.

I did a fresh install with 4.1.0-20051112. Look at my posts above.

Tiger683 · Post by **Tiger683** » Sun Nov 13, 2005 8:41 am

everything that compiles with gcc4 in general can be made to compile
with 4.1_beta... i pruned my gcc3.x.x on this testbox right after bootstrap, and have a full kde desktop now....
EDIT: svgalib compiled just fine as well, although i use same binutils as curtis does...no idea what's up,
unless in was NOT a binutils issue on his side...

wrc1944 · Post by **wrc1944** » Sun Nov 13, 2005 11:51 am

curtis119,

I reread your posts above, and unless I just missed it, you only mention gcc-4.1.0_beta20051105. I was assuming beta20051112 had made a little more progress, so before I tried updating up from 4.0.2, I thought I'd ask those using 4.1 what their experience was. The gcc website is currently unavailable, and a google seach for gcc-4.1.0_beta20051112 turned up nothing.

nmbrthry,
Thanks for the clarification on your tests.

Tiger683 · Post by **Tiger683** » Sun Nov 13, 2005 12:37 pm

wrc1944 wrote:curtis119,

I reread your posts above, and unless I just missed it, you only mention gcc-4.1.0_beta20051105. I was assuming beta20051112 had made a little more progress, so before I tried updating up from 4.0.2, I thought I'd ask those using 4.1 what their experience was. The gcc website is currently unavailable, and a google seach for gcc-4.1.0_beta20051112 turned up nothing.

nmbrthry,
Thanks for the clarification on your tests.

I'm reemerging -e world after upgrade to 4.1_beta20051112 and rebuilding the toolchain. Now it would be time to push it a little further, so i enabled vectorization in CFLAGS. 20051105 built xorg was running normally from what i can say, in a previous post i already stated (somehow clumsy) the build of system with 20051105, but most had been already found out..oh, well..
I'll report back when i'm done with compiling and (hopefully) in X.

cheers

T

wrc1944 · Post by **wrc1944** » Mon Nov 14, 2005 8:00 am

After emerging gcc-4.1_beta20051112, I just did an emerge -e system (96 packages) with 4.._beta20051112, and all compiled fine with these flags, except groff-1.19.1-r2:

CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -ftree-vectorize -falign-functions=64"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fno-enforce-eh-specs"

Apparently groff-1.19.2 out, released on 2005-09-07, but no ebuild for it as yet. and groff-1.19.1-r2 is from 2005-09-29. Very curious. No ebuilds for psselect.

I removed -ftree-vectorize, and still got exactly the same errors, below, so that's not it. Groff did compile before with 4.0.2, and all the above flags, except -ftree-vectorize, but as I mentioned, removing it didn't help.
----------------------------------------------------------------------------
checking for gs... found
configure: WARNING:

The program
`psselect'
can't be found in the path, thus the HTML backend of groff (grohtml)
won't work properly. Consequently, no documentation in HTML format
is built and installed.

---------------
er -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -c table.cpp
i686-pc-linux-gnu-g++ -I. -I. -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -c input.cpp
input.cpp: In function 'void exit_troff()':
input.cpp

error: 'process_input_stack' was not declared in this scope
input.cpp

error: 'end_diversions' was not declared in this scope
input.cpp: In function 'void process_input_stack()':
input.cpp

error: 'title' was not declared in this scope
Making tbl.n from tbl.man
------------------
make[2]: Entering directory `/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/preproc/pic'
i686-pc-linux-gnu-g++ -I. -I. -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -c pic.cpp
make[2]: *** [input.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/roff/troff'
make[1]: *** [src/roff/troff] Error 2
make[1]: *** Waiting for unfinished jobs....
------------------------------------------------
i686-pc-linux-gnu-g++ -I. -I. -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -c troff.cpp
i686-pc-linux-gnu-g++ -I. -I. -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -I/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/include -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -c tex.cpp
Making pic.n from pic.man
i686-pc-linux-gnu-g++ -O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -ftracer -fprefetch-loop-arrays -fno-ident -falign-functions=64 -fvisibility-inlines-hidden -fno-enforce-eh-specs -o pic pic.o lex.o main.o object.o common.o troff.o tex.o /var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/libs/libgroff/libgroff.a -lm
make[2]: Leaving directory `/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1/src/preproc/pic'
make[1]: Leaving directory `/var/tmp/portage/groff-1.19.1-r2/work/groff-1.19.1'
make: *** [all] Error 2

!!! ERROR: sys-apps/groff-1.19.1-r2 failed.
!!! Function src_compile, Line 86, Exitcode 2
----------------------------------------------------------

UPDATE: Got it to work- I added -ftree-vectorize back into cflags, and added -ffriend-injection to CXXFLAGS, and groff compiled fine. So to summarize, I have completed one emerge -e system with gcc-4.1_beta20051112 with the above flags, and adding -ffriend-injection to CXXFLAGS for groff only. Is it a good idea to leave in -ffriend-injection for another emerge -e system and emerge -e world?

I wish I actually had a better grasp of what I was doing- I know virtually nothing about programming.

Tiger683 · Post by **Tiger683** » Mon Nov 14, 2005 8:11 am

wrc1944 wrote: Is it a good idea to leave in -ffriend-injection for another emerge -e system and emerge -e world?

As i already stated, it is kind of cruicial, as many other packages use the deprecated syntax too..
-ftree-vectorize works just fine here for the whole installation. To summarize:
the error with class qualifier inside of class prototype arized once again after aspell,
but no further compile failures, system seems more snappy than on my gcc-4.0.2 box

I have gotten composite to work with kde-3.5-rc1 (svn update) and everything i need so far,
the new binutils seems also to behave well with --as-needed.

although, adding kdeenablefinal in case of kde users prevents kdelibs from dying with linker errors.
( YYY.o (text+0xXXX) redefined blabla)

cheers

T

Tiger683 · Post by **Tiger683** » Mon Nov 14, 2005 8:30 am

i used these for the whole 4.1_beta20051112 system (binutils 2.16.91.0.3):

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s"

two packages didn't like the --as-needed so far

wrc1944 · Post by **wrc1944** » Mon Nov 14, 2005 8:58 am

Tiger683- Thanks for the info! Guess I'll forge ahead with -e world.

In my googling for more gcc-4.1 info, I ran across a thread where some setiathome people were discussing 4.1, and the gcc-4.1 flags -fwhole-program and -combine, as related to ICC and GCC performance. Lots of things I've read over the last 2 years seem to concur that GCC performance still significantly lags behind ICC compiled code, and was one reason Linux performance seemed to lag behind windows on the same hardware. My own experience with windows vs. Linux using many versions of each on many boxes seems to confirm this pretty convincingly, though lately Linux does seem to be closing the gap.
Has anyone had experience with, or is planning to try these flags? Seems very interesting to me. Here's a few excerpts, and a link to the rather long thread (if anyone's interested).

I have a vested interest in finding out. During my forays with GCC-4.1, I
found and submitted two bug reports that got fixed with breathtaking speed.
So my hope is that the current CVS version of GCC-4.1 is better than 4.0.x.
I'll wait to hear from you all. If you're really aggressive about this, you
should know that GCC-4.1 has a new option, similar to ICC's -ipo, which
allows you to compile all source files on one line and get much better
optimization between modules. The options, which are used together, are
-fwhole-program and -combine (might be off a bit) It would be cool if you
could try that, because -ipo adds a lot of performance to ICC-compiled code.
But, of course, you'd have to completely redo the Makefiles.
____________
Harold Naparst
-------------------------------------------------------------------------
Posted 20 Oct 2005 6:57:53 UTC - in response to Message ID 180113.

Right. Well, it is confusing with all the options, so I'm glad we
have all these people working on it. I'd be interested to know if
you all think GCC-4.1 is faster than GCC-4.0.x and if there is any
advantage at all to ICC/IPP once the dust settles, or if it only
exists for P4. Good job, guys!!
-------------------------------------------------------------------------------
Well, I'm certainly no expert here, but it would seem to me that you are able
to get good (fast) results with ICC relatively quickly and with relatively
few compiler optimizations. GCC, on the other hand, is extremely dependent
upon optimization flags - the right set of flags can make a huge difference
to performance. Equally, some flags are actually detrimental to performance
even though you may think they would be beneficial. Bottom line is that a lot
of benchtesting against a reference WU is required to find optimal settings.

The speed improvements gained fron going from GCC-3.x.x to GCC-4.x.x were
large relative to improvements between point releases. I've not tried GCC-4.1
yet but I would guess it may provide relatively small speed improvements.

Ned
-------------------------------------------------

http://setiathome.berkeley.edu/forum_th ... p?id=21239

nxsty · Post by **nxsty** » Mon Nov 14, 2005 9:27 am

wrc1944 wrote:Tiger683- Thanks for the info! Guess I'll forge ahead with -e world.

In my googling for more gcc-4.1 info, I ran across a thread where some setiathome people were discussing 4.1, and the gcc-4.1 flags -fwhole-program and -combine, as related to ICC and GCC performance. Lots of things I've read over the last 2 years seem to concur that GCC performance still significantly lags behind ICC compiled code, and was one reason Linux performance seemed to lag behind windows on the same hardware. My own experience with windows vs. Linux using many versions of each on many boxes seems to confirm this pretty convincingly, though lately Linux does seem to be closing the gap.
Has anyone had experience with, or is planning to try these flags? Seems very interesting to me. Here's a few excerpts, and a link to the rather long thread (if anyone's interested).

-combine are available in gcc4 already but I haven't tried it myself yet. -fwhole-program seems really intersting too. I'll do some benchmarks on -combine and get back to you later.

Btw, Linux usually kicks winxp/2003's ass on the same hardware. It's only the GUI responsiveness that Linux and other *nix clones laggs behind.

Tiger683 · Post by **Tiger683** » Mon Nov 14, 2005 1:23 pm

thersites wrote:this is the patch i've been using with groff-1.19.1-r2

Not needed with -ffriend-injection CXXFLAG set....
same breakage will occur with many other packages in a full-fledged system,
lots of PITA when patching every single one

Tiger683 · Post by **Tiger683** » Mon Nov 14, 2005 11:32 pm

hmm, nothing seroius to report so far, full fledged kde system up and running, gcc-4.1 only...

seren · Post by **seren** » Mon Nov 14, 2005 11:49 pm

im trying to compile gcc-4.1-20051112 but i get this message...

Code: Select all

>> md5 files   ;-) files/3.3.3/gcc-3.3.3-uclibc-add-ssp.patch
>>> md5 files   ;-) files/3.3.3/gcc-uclibc-3.3-loop.patch
>>> md5 files   ;-) files/3.3.3/gcc333-debian-arm-ldm.patch
>>> md5 files   ;-) files/3.3.3/gcc333-debian-arm-getoff.patch
>>> md5 files   ;-) files/3.3.3/gcc333_pre20040408-stack-size.patch
>>> md5 files   ;-) files/3.4.3/libssp.patch
>>> md5 files   ;-) files/3.4.3/gcc-3.4.3-cross-compile.patch
>>> md5 files   ;-) files/3.4.3/libffi-nogcj-lib-path-fix.patch
>>> md5 files   ;-) files/3.4.3/libffi-without-libgcj.patch
>>> md5 files   ;-) files/3.3.4/libffi-without-libgcj.patch
>>> md5 files   ;-) files/3.4.4/gcc-3.4.4-cross-compile.patch
>>> md5 files   ;-) files/3.4.4/gcc-3.4.4-softfloat.patch
>>> md5 files   ;-) files/3.3.5/gcc-3.3.5-ffecom_gfrt_basictype-prototype.patch
>>> md5 files   ;-) files/3.3.5/gcc-3.3.5-no-COPYING-cross-compile.patch
>>> md5 files   ;-) files/3.3.6/gcc-3.3.6-cross-compile.patch
>>> md5 src_uri ;-) gcc-4.1-20051112.tar.bz2
!!! ERROR: sys-devel/gcc-4.1.0_beta20051112 failed.
!!! Function pkg_setup, Line 49, Exitcode 0
!!! Please `export I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS=1` or define it in your make.conf if you want to use this ebuild.  This is to try and cut down on people filing bugs for a compiler we do not currently support.
!!! If you need support, post the topmost build error, NOT this status message.
Done.

this is a newly built system, i was plaining on doing a benchmark but i think its very odd i cant compile 4.1.0 with 4.0.2 im going to see if 4.0.2 is the problem also going to emerge 2.16.9X of binutils (?) i have 2.16.1. have 2.3.6 glibc already... heres emerge --info

Code: Select all

Portage 2.0.53_rc7 (default-linux/x86/2005.1, gcc-4.0.2, glibc-2.3.6-r0, 2.6.14-nitro2 i686)
=================================================================
System uname: 2.6.14-nitro2 i686 Intel(R) Celeron(R) CPU 2.40GHz
Gentoo Base System version 1.12.0_pre10
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5, 2.4.2
sys-apps/sandbox:    1.2.13
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-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/lib/X11/xkb /usr/li b/mozilla/defaults/pref /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict userpriv"
GENTOO_MIRRORS="http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="x86 X alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 crypt cups eds emboss encode esd exif ex pat fam foomaticdb fortran gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 idn imlib ipv6 java jpeg kde lc ms libg++ libwww mad mikmod mng motif mozilla mp3 mpeg ncurses nls ntpl ntplonly ogg oggvorbis opengl oss  pam pcre pdflib perl png python qt quicktime readline sdl spell ssl tcpd tiff truetype truetype-fonts ty pe1-fonts udev usb vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS

wrc1944 · Post by **wrc1944** » Mon Nov 14, 2005 11:58 pm

Got through emerge -e system twice perfectly, now on package 123 of 269 on emerge -e world, no problems yet. Got through xorg OK- coming up on qt and kde in a few minutes. I'm still using the aggressive new flags I posted above. If even I can get through these last -e world packages OK, I'm thinking gcc-4.1_beta20051112 could be put into ~x86, and really get a lot of users working on it. After all, 4.x is already the default for a few mainstream distros.

seren · Post by **seren** » Tue Nov 15, 2005 12:13 am

i get the same error with binutils 2.16.91.0.3..... is it something else? i have sane cflags no ldflags.. anyone tried to compile 4.1.0 with 4.0.2?

wrc1944 · Post by **wrc1944** » Tue Nov 15, 2005 12:56 am

I compiled 4.1 with 4.0.2, and then compiled 4.1 with itself, but I'm running pure ~x86, and am using the latest binutils-2.16.1, and pretty heavy cflags (see my post above).

Also, you need to put the line:

I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS=1

in your /etc/make.conf file, as the error said.

wrc1944 · Post by **wrc1944** » Tue Nov 15, 2005 1:15 am

Also, don't forget to add -ffriend-injection to CXXFLAGS. (See Tiger683's posts above). Otherwise groff and other packages might start breaking.