RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Zaborowski, Ed, Ctr, AFPCA/OAC]

I don't believe you should _have_ to recompile your kde packages (I could be
wrong), but I would think it would seem reasonable that you should get a
performance gain recompiling those with the -march=athlon-tbird
-fomit-frame-pointer -O3 flags.

-----Original Message-----
From: Prashanth Aditya Susarla [mailto:aditya@iitk.ac.in] 
Sent: Monday, June 03, 2002 12:57 PM
To: 'gentoo-dev@gentoo.org'
Subject: RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

> -fomit-frame-pointer -O3 (I had to ebuild parts of Xfree manually so I
could
> change the flags in certain areas to get it to compile, and I also had to

Somehow I couldn't manage to do this. There was this problem with one 
particular component (don't remember which, it was posted in one thread on 
this mailing list earlier this month) and there was a quickfix solution 
to it which said that it could be built manually in $PORTAGE_TMPDIR. I 
tried it with all combinations of flags but I couldn't get it to work. 
Ultimately I had to rebuild entire xfree with -march=i686 -O3 
-fomit-frame-pointer -pipe.

I had almost forgotten that qt doesn't honor make.conf and I went ahead 
and built it and to my consternation saw it was using measly -O2 (and no 
architecture-specific) flags. I think I'll just rebuild qt after I am done 
with kde entirely.

Will it be necessary for me to recompile KDE if I recompile qt with these 
newer flags? I shouldn't think so because I don't see any 
qt-statically-linked components in KDE.

Regards,
Prashanth Aditya Susarla


_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev

RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

There seems to be a tangible gain in performance. I've also employed 
Casey's tips to improved KDE performance and it's all paying off. At this 
moment, I have yet to merge kdemultimedia and kdeaddons which at the 
moment cannot be merged because of the xanim problem. KDE otherwise seems 
to be working fine. Konqueror, kcontrol... the works. They are all doing 
fine.
At this moment, bitchx is segfaulting and irssi won't emerge. BitchX 
segfaults and I think this has got to do something with the 
compiler/flags. Will look at it with slightly less aggressive flags.

Regards,
Prashanth Aditya Susarla

On Tue, 4 Jun 2002, Zaborowski, Ed, Ctr, AFPCA/OAC wrote:

> I don't believe you should _have_ to recompile your kde packages (I could be
> wrong), but I would think it would seem reasonable that you should get a
> performance gain recompiling those with the -march=athlon-tbird
> -fomit-frame-pointer -O3 flags.

RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Zaborowski, Ed, Ctr, AFPCA/OAC]

I myself, am in the middle of compiling kdelibs, and will let you know how
kdemultimedia goes shortly. 

The flags I used for boot-strap were -march=athlon-tbird -O3
Everything else has been compiled using -march=athlon=tbird
-fomit-frame-pointer -O3 (I had to ebuild parts of Xfree manually so I could
change the flags in certain areas to get it to compile, and I also had to
modify and ebuild manually qt because, the I had to add those flags
specifically to qt's qmake.conf. It apparently doesn't honor the settings in
make.conf)



-----Original Message-----
From: Matthew Kennedy [mailto:mkennedy@gentoo.org] 
Sent: Tuesday, June 04, 2002 1:12 PM
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

Prashanth Aditya Susarla <aditya@iitk.ac.in> writes:

> I have yet to compile  qt and kde and going by what I've seen about these 
> builds vis-a-vis gcc 3.1 I just might have to go easy again on the 
> optimization flags a bit (like I did for xfree).

I'd be very interested to hear how compiling KDE (kdemultimedia in
particular) goes for you with those flags.

Thanks

-- 
Matthew Kennedy
Gentoo Linux Developer
Bugs go in http://bugs.gentoo.org!

_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev

RE: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

> -fomit-frame-pointer -O3 (I had to ebuild parts of Xfree manually so I could
> change the flags in certain areas to get it to compile, and I also had to

Somehow I couldn't manage to do this. There was this problem with one 
particular component (don't remember which, it was posted in one thread on 
this mailing list earlier this month) and there was a quickfix solution 
to it which said that it could be built manually in $PORTAGE_TMPDIR. I 
tried it with all combinations of flags but I couldn't get it to work. 
Ultimately I had to rebuild entire xfree with -march=i686 -O3 
-fomit-frame-pointer -pipe.

I had almost forgotten that qt doesn't honor make.conf and I went ahead 
and built it and to my consternation saw it was using measly -O2 (and no 
architecture-specific) flags. I think I'll just rebuild qt after I am done 
with kde entirely.

Will it be necessary for me to recompile KDE if I recompile qt with these 
newer flags? I shouldn't think so because I don't see any 
qt-statically-linked components in KDE.

Regards,
Prashanth Aditya Susarla

[gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

>do -not- use  -fomit-frame-pointer during bootstrap! (can anyone who
>actually got this to -work- using omit-frame-pointer speak up??) 
>
>This causes breakage in glibc.

That's interesting. When I used default-1.0, I used all the flags which
one particular FAQ on gentoo.org mentioned (-fforce-addr
-fomit-frame-pointer -funroll-loops blah blah blah along with -march=i686
-O3 of course) and everything worked fine (atleast compiled fine though I
was not truly happy with the performance (lots of memory leaks and
subsequent crashes of kswapd primarily). So maybe this is an issue only
with gcc-3.x and/or binutils-2.12.x. But I toned down the optimizations
and the bootstrap worked fine.

>this is due to a broken glibc (omit frame pointer and -O3. I think glibc
>strips out -O3 but  not the -f flags. )

gcc does this. glibc retains whatever you specify. Anyway, that's beside
the point - only for the sake of information ;-).

>> problem is that most binaries segfault soon after glibc is built.
>Try again with -O2 -pipe  and you will get a working system :)

Infact, I finally used the default options for Athlon systems (-march=i686
-pipe -O3.... not -O2 but -O3) and glibc didn't break. As I said earlier,
this is strange because all those crazy optimizations worked in the case
of the default-1.0 profile. 

>emerge system
>/(watch it break down and cry in xfree because you overoptimized)

So you're saying that if I use -march=athlon-tbird -fomit-frame-pointer
-O3 [-pipe] -mmmx -m3dnow (the latter only for the sake of multimedia apps
like xmms, mplayer etc.) the xfree ebuild b0rks out? That's too bad,
really. And the thing with xfree is that experimenting stops being an
option if the very first emerge itself doesn't work :-(. Not all of us
have all the time in the world...

Regards,
Prashanth Aditya Susarla

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Bart Verwilst]

Would be cool if you could try and bootstrap again with -fomit-frame-pointer, 
and now use the 1.3-gcc3.1 tarball from ibiblio 
(http://www.ibiblio.org/gentoo/releases/build/) i just made. If it fails, i 
guess we should filter out most of the optimisations... I think the new 
gcc3.1-compiled tarball will make all the gcc3.1-users much happier :o)
I also updated the packages file from the gcc 3.1 profile, and the 
make.defaults. Please keep us posted on any progress!

Thanks!


On Sunday 02 June 2002 19:42, Prashanth Aditya Susarla wrote:
|| >do -not- use  -fomit-frame-pointer during bootstrap! (can anyone who
|| >actually got this to -work- using omit-frame-pointer speak up??)
|| >
|| >This causes breakage in glibc.
||
|| That's interesting. When I used default-1.0, I used all the flags which
|| one particular FAQ on gentoo.org mentioned (-fforce-addr
|| -fomit-frame-pointer -funroll-loops blah blah blah along with -march=i686
|| -O3 of course) and everything worked fine (atleast compiled fine though I
|| was not truly happy with the performance (lots of memory leaks and
|| subsequent crashes of kswapd primarily). So maybe this is an issue only
|| with gcc-3.x and/or binutils-2.12.x. But I toned down the optimizations
|| and the bootstrap worked fine.
||
|| >this is due to a broken glibc (omit frame pointer and -O3. I think glibc
|| >strips out -O3 but  not the -f flags. )
||
|| gcc does this. glibc retains whatever you specify. Anyway, that's beside
|| the point - only for the sake of information ;-).
||
|| >> problem is that most binaries segfault soon after glibc is built.
|| >
|| >Try again with -O2 -pipe  and you will get a working system :)
||
|| Infact, I finally used the default options for Athlon systems (-march=i686
|| -pipe -O3.... not -O2 but -O3) and glibc didn't break. As I said earlier,
|| this is strange because all those crazy optimizations worked in the case
|| of the default-1.0 profile.
||
|| >emerge system
|| >/(watch it break down and cry in xfree because you overoptimized)
||
|| So you're saying that if I use -march=athlon-tbird -fomit-frame-pointer
|| -O3 [-pipe] -mmmx -m3dnow (the latter only for the sake of multimedia apps
|| like xmms, mplayer etc.) the xfree ebuild b0rks out? That's too bad,
|| really. And the thing with xfree is that experimenting stops being an
|| option if the very first emerge itself doesn't work :-(. Not all of us
|| have all the time in the world...
||
|| Regards,
|| Prashanth Aditya Susarla

-- 
Bart Verwilst
Gentoo Linux Developer, Desktop Team
Gent, Belgium

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

Great work. I'll definitely try it out. Can I use the -march=athlon-tbird
flag at the outset with this build image? I guess I can.
About some more developments - I followed Spider's "recipe" (as he calls
it :-)) to build a gcc-3.1 system and I must say it works great. I stored
away the safe packages and then changed the optmizations a bit. The system
always complains whenever glibc is compiled with -fomit-frame-pointer. I
kept the other flags intact and just removed this, and again everything is
perfect. I think this new gcc-3.1 tarball had to come out...

Regards,
Prashanth

On Sun, 2 Jun 2002, Bart Verwilst wrote:

>Would be cool if you could try and bootstrap again with -fomit-frame-pointer, 
>and now use the 1.3-gcc3.1 tarball from ibiblio 
>(http://www.ibiblio.org/gentoo/releases/build/) i just made. If it fails, i 
>guess we should filter out most of the optimisations... I think the new 
>gcc3.1-compiled tarball will make all the gcc3.1-users much happier :o)
>I also updated the packages file from the gcc 3.1 profile, and the 
>make.defaults. Please keep us posted on any progress!
>
>Thanks!

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

>and now use the 1.3-gcc3.1 tarball from ibiblio 

I think it's missing /usr/sbin/install-info. So emerge skips the info
regeneration step after each emerge. Don't know how serious this could be
but it's to be looked at I suppose.

Regards,
Prashanth

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

On Mon, 3 Jun 2002, Prashanth Aditya Susarla wrote:

>>and now use the 1.3-gcc3.1 tarball from ibiblio 

The build fails with this tarball also on using -fomit-frame-pointer. The
same situation happens ie. most binaries go haywire.

Regards,
Prashanth

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Brian Webb]

I tried the 1.3-gcc3.1 profile but ran into some problems, and now I can't
get any 3.0 profile to work!
I first booted from a 1.1a stage1 CD, I then downloaded an untared the
1.3-gcc3.1 stage1, changed the CFLAGS and CXXFLAGS in make.conf to
"-march=athlon-xp -O3 -pipe", and bootstrapped.
I soon realized that make.profile was pointing to the default profile when
it started building gcc-2.95.3.  Since this is a 3.1 bootstrap, it seems
like the default make.profile link should be to the 3.0 profile instead,
but that wasn't a problem.  I started over, remembering to change the
make.profile link, and bootstrap finished successfully.
There were some errors about info files (this was mentioned in a previous
email), but I didn't think much of them.  Unfortunately, the "emerge
system" step failed when building e2fsprogs because it couldn't find
makeinfo.
While I was trying to figure out how to build makeinfo I decided to
"emerge rsync" just in case something had gotten fixed in the last couple
of hours ;-).  That's when things really fell apart.  After that I
couldn't get any emerges to work.  I kept getting "Couldn't find match
for..." from emerge.
At this point I decided that something was really messed up, so decided to
start over from a more standard gcc-3.1 bootstrap that worked for me just
a day or two ago.
I have successfully bootstrapped on a similar system using a 1.1a stage1
and the 3.0 make profile as long as I don't change the CFLAGS or CXXFLAGS
until the "emerge system" step (after the gcc 3.1 compiler has been
built).  Unfortunately, this is no longer working either.
I now get the "Couldn't find match for..." error messages almost
immediately after running bootstrap.sh.  The error messages start just
after portage has been emerged.  Has something recently changed with
portage or the gcc 3.0 profile that could have caused this?  Any idea how
I can fix this?
Brian

> Would be cool if you could try and bootstrap again with
> -fomit-frame-pointer,  and now use the 1.3-gcc3.1 tarball from ibiblio
> (http://www.ibiblio.org/gentoo/releases/build/) i just made. If it
> fails, i  guess we should filter out most of the optimisations... I
> think the new  gcc3.1-compiled tarball will make all the gcc3.1-users
> much happier :o) I also updated the packages file from the gcc 3.1
> profile, and the  make.defaults. Please keep us posted on any progress!

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Brian Webb]

I think I may have found at least part of the problem.  I noticed that on
my other gcc-3.0 profile machines, texinfo couldn't be emerged.  It turns
out that texinfo is masked.  Texinfo is a required system package in the
gcc-3.0 profile and it's masked the package.mask, which obviously is not a
good thing.  If I unmask texinfo my existing systems are happy, but I
haven't tested it on a bootstrap yet.

Brian


P.S. Sorry about the run-on emails.  I really have to figure out why
Squirrelmail is running all my paragraphs together!!!!

> I tried the 1.3-gcc3.1 profile but ran into some problems, and now I
> can't get any 3.0 profile to work!

> I first booted from a 1.1a stage1 CD, I then downloaded an untared the
> 1.3-gcc3.1 stage1, changed the CFLAGS and CXXFLAGS in make.conf to
> "-march=athlon-xp -O3 -pipe", and bootstrapped.

> I soon realized that make.profile was pointing to the default profile
> when it started building gcc-2.95.3.  Since this is a 3.1 bootstrap, it
> seems like the default make.profile link should be to the 3.0 profile
> instead, but that wasn't a problem.  I started over, remembering to
> change the make.profile link, and bootstrap finished successfully.

> There were some errors about info files (this was mentioned in a
> previous email), but I didn't think much of them.  Unfortunately, the
> "emerge system" step failed when building e2fsprogs because it couldn't
> find makeinfo.

> While I was trying to figure out how to build makeinfo I decided to
> "emerge rsync" just in case something had gotten fixed in the last
> couple of hours ;-).  That's when things really fell apart.  After that
> I couldn't get any emerges to work.  I kept getting "Couldn't find
> match for..." from emerge.

> At this point I decided that something was really messed up, so decided
> to start over from a more standard gcc-3.1 bootstrap that worked for me
> just a day or two ago.

> I have successfully bootstrapped on a similar system using a 1.1a
> stage1 and the 3.0 make profile as long as I don't change the CFLAGS or
> CXXFLAGS until the "emerge system" step (after the gcc 3.1 compiler has
> been built).  Unfortunately, this is no longer working either.
> I now get the "Couldn't find match for..." error messages almost
> immediately after running bootstrap.sh.  The error messages start just
> after portage has been emerged.  Has something recently changed with
> portage or the gcc 3.0 profile that could have caused this?  Any idea
> how I can fix this?
> Brian
>
>> Would be cool if you could try and bootstrap again with
>> -fomit-frame-pointer,  and now use the 1.3-gcc3.1 tarball from ibiblio
>> (http://www.ibiblio.org/gentoo/releases/build/) i just made. If it
>> fails, i  guess we should filter out most of the optimisations... I
>> think the new  gcc3.1-compiled tarball will make all the gcc3.1-users
>> much happier :o) I also updated the packages file from the gcc 3.1
>> profile, and the  make.defaults. Please keep us posted on any
>> progress!
>
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

I've managed to get a working system up and running on gcc-3.1. I used the 
1.3-gcc3.1 stage1 tarball with the following optimizations:-
-march=athlon-tbird -mmmx -m3dnow -O3 -pipe (no -fomit-frame-pointer). The 
mmx and 3dnow flags are obviously only cosmetic at this stage but there 
was no problem with -O3.
There was that problem with xfree, which I could solve by using 
-march=i686 -O3 -pipe (again no -fomit-frame-pointer and -O3 caused no 
problems).
Since -fomit-frame-pointer used to work everywhere with gcc-2..95.x, I 
find it somewhat strange that it should b0rk out with gcc-3.1. It's maybe 
because of changes in the compiler itself, or maybe because of the 
software itself - which the earlier compiler let through without any fuss.
The second looks more likely because my regular optimization flags (for 
the system builds as well as world builds) are -march=-athlon-tbird -mmmx 
-m3dnow -O3 -pipe -fomit-frame-pointer and there's absolutely no problem.
I have yet to compile  qt and kde and going by what I've seen about these 
builds vis-a-vis gcc 3.1 I just might have to go easy again on the 
optimization flags a bit (like I did for xfree).

Regards,
Prashanth Aditya Susarl

On Sun, 2 Jun 2002, Brian Webb wrote:

> I think I may have found at least part of the problem.  I noticed that on
> my other gcc-3.0 profile machines, texinfo couldn't be emerged.  It turns
> out that texinfo is masked.  Texinfo is a required system package in the
> gcc-3.0 profile and it's masked the package.mask, which obviously is not a
> good thing.  If I unmask texinfo my existing systems are happy, but I
> haven't tested it on a bootstrap yet.
> 
> Brian
> 
> 
> P.S. Sorry about the run-on emails.  I really have to figure out why
> Squirrelmail is running all my paragraphs together!!!!

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Matthew Kennedy]

Prashanth Aditya Susarla <aditya@iitk.ac.in> writes:

> I have yet to compile  qt and kde and going by what I've seen about these 
> builds vis-a-vis gcc 3.1 I just might have to go easy again on the 
> optimization flags a bit (like I did for xfree).

I'd be very interested to hear how compiling KDE (kdemultimedia in
particular) goes for you with those flags.

Thanks

-- 
Matthew Kennedy
Gentoo Linux Developer
Bugs go in http://bugs.gentoo.org!

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

kdemultimedia doesn't compile at all because it has a dependency on xanim. 
And there's some problem with xa_x11.c (which I don't know whether it's 
being caused by gcc-3.1 + such heavy optimization or otherwise). Anyway, 
kdelibs, kdebase, kdeadmin, kdeartwork (even arts) have gone on smoothly 
enough. I am completing the rest of the kde packages now and will look at 
xanim/kdemultimedia again. At the outset, I can't find any USE flag which 
might make kdemultimedia want to depend on xanim. If I find something like 
that, I will un-USE it and proceed with kdemultimedia.

Regards,
Prashanth Aditya Susarla

On 4 Jun 2002, Matthew Kennedy wrote:
> 
> I'd be very interested to hear how compiling KDE (kdemultimedia in
> particular) goes for you with those flags.
> 
> Thanks
> 
> -- 
> Matthew Kennedy
> Gentoo Linux Developer
> Bugs go in http://bugs.gentoo.org!

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Christian Hergl]

Hi all together,

just to let ya know, I emerged kdemultimedia successfully with the -O2 
optimation. -O3 seems to be too strong. Problem is knowen and worked on.

Regards,
Christian

Prashanth Aditya Susarla wrote:
> kdemultimedia doesn't compile at all because it has a dependency on xanim. 
> And there's some problem with xa_x11.c (which I don't know whether it's 
> being caused by gcc-3.1 + such heavy optimization or otherwise). Anyway, 
> kdelibs, kdebase, kdeadmin, kdeartwork (even arts) have gone on smoothly 
> enough. I am completing the rest of the kde packages now and will look at 
> xanim/kdemultimedia again. At the outset, I can't find any USE flag which 
> might make kdemultimedia want to depend on xanim. If I find something like 
> that, I will un-USE it and proceed with kdemultimedia.
> 
> Regards,
> Prashanth Aditya Susarla
> 
> On 4 Jun 2002, Matthew Kennedy wrote:
> 
>>I'd be very interested to hear how compiling KDE (kdemultimedia in
>>particular) goes for you with those flags.
>>
>>Thanks
>>
>>-- 
>>Matthew Kennedy
>>Gentoo Linux Developer
>>Bugs go in http://bugs.gentoo.org!
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Re: [gentoo-dev] Re: GCC3.1 bootstrap fails

[Prashanth Aditya Susarla]

Yeah actually I was about to post this one but I thought I'd check out 
bugs.gentoo first. xanim finally compiled (with the r4 revision) so I 
thought I'll go ahead with kdemultimedia and kdeaddons and both of them 
crapped out while compile. So if -O2 works, so be it :-(.

Regards,
Prashanth

On Wed, 5 Jun 2002, Christian Hergl wrote:

> Hi all together,
> 
> just to let ya know, I emerged kdemultimedia successfully with the -O2 
> optimation. -O3 seems to be too strong. Problem is knowen and worked on.
> 
> Regards,
> Christian