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 attachment 43199 [details] my emerge --info
Comment on attachment 43199 [details] my emerge --info 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
