Bugzilla Bug 69536

With my normal CFLAGS Grip displays the Rip and Enc speeds ( under the Rip tab
) as 0.0x, sometimes it will creep up, but it's definetly not accurate as it's
actually ripping and encoding the tracks.

I'm not sure if this will follow portage standards, but this is what I added at
the top of my 3.2.0 ebuild to fix it:
inherit flag-o-matic

append-flags "-mcpu=i586"

ALLOWED_FLAGS="-O -O1 -O2 -Os -O3 -mcpu -pipe -fomit-frame-pointer"
strip-flags


The append-flags is unnecessary/won't play nice with other arches, I know. I
also tried without the append-flags and it works fine, so that would be the
more generic-make-everyone-happy route.

Reproducible: Always
Steps to Reproduce:

please give me your 'emerge --info' output.  It's probablt a flag that you have
enabled.  Please try to figure out what flag you enable that causes this
problem.

Created an attachment (id=43199) [details]
my emerge --info

(From update of attachment 43199 [details])
I've had this problem for a long time actually, with many different flags. The
only flag that's stayed the same is -march=athlon-mp. I think I've even tried
other -march options, but I finally got it to work at -mcpu=i686

what if you add -mno3dnow -mnosse to CFLAGS?

Hm, well -mno-3dnow doesn't change anything, but -mno-sse makes the speed
display correctly.
Thanks :)

append-flags "-mno-sse" at the top of the next grip ebuild probably wouldn't
hurt future users.

ok, the append flag is in portage...

would you mind testing this problem when you update to gcc-3.4 to see if it's fixed with that compiler... if it works with gcc-3.4, just reopen this bug so I can make the flag magic conditional on the gcc version.

Thanks.

Tried compiling with and without -mno-sse and gcc-3.4.3
The results are the same, gcc-3.4.x needs -mno-sse

this was fixed about a month ago in portage ... closing