HI folks, while updating media-libs/libpng-1.2.5-r1 following error message appered: [...] gcc -I/usr/include -Wall -march=k6 -O3 -pipe -fomit-frame-pointer -funroll-loops -c -o pngrtran.o pngrtran.c {standard input}: Assembler messages: {standard input}:1088: Error: value of ffffffffffffff7f too large for field of 1 bytes at 0000000000001019 make: *** [pngrtran.o] Error 1 !!! ERROR: media-libs/libpng-1.2.5-r1 failed. !!! Function src_compile, Line -90, Exitcode 2 !!! (no error message) I have been using CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer" and again (like a previos bug i reported on mysql) thats the problem! SOLUTION: Using CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer" solves this problem again, so i recommend to insert the following lines into the libpng-1.2.5-r1.ebuild: inherit flag-o-matic replace-flags "-march=k6-3" "-march=i586" replace-flags "-march=k6-2" "-march=i586" replace-flags "-march=k6" "-march=i586" with regards Sascha Herrmann
What about tuning down on optimisations ? O2 and the like any effect ?
No, replacing -O3 with -O2 had no effect, it's the -march=k6 flag, as i discovered this error this evening again in graphivx! And there it was the same fault. This kind of errors increased in number since i updated to new stable binutils and gcc-3.2.1, but i found some of them even before (like in bug#11681 !) bye Sascha
would be nice if someone could pin it down on a certain pack, so we can send a bugreport upstream. I'll fix the libpng ebuild.
H
Hähh, how do you mean "pin it down on a certain pack"???? if you need more proofs for my report, i can send you all my error log that i solved with downgrading form -march=k6 to -march=i586! This problem can't be assigned to a certain combination of packages, because it seems to be a bug in the combination of binutils and gcc (and i had at least 2*2 different combinations with similar errors!) The problem is that binary code is produced, that doesn't do would it#s supposed to do! bye Sascha
4 different combinations ? ;) And i know what the problem is yeah anyway, fixed in the tree
How I solved it: I used CFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer" and got the same error. However, the problem for me was not the -march param. It was -fomit-frame-pointer. (I had a similer problem with net-print/cups. See bug #13471.) I removed -fomit-frame-pointer from the CFLAGS, and it built fine! :) That's my experiance. So, you just might not need to change -march after all. :)
Can you confirm that sascha ?
Hmm, for the "K6-2" i can confirm hezekiah version. Yes it works without -fomit-frame.. for the "K6", yes it even works for k6 arch without -fomit-frame... Maybe that
Hmm, for the "K6-2" i can confirm hezekiah version. Yes it works without -fomit-frame.. for the "K6", yes it even works for k6 arch without -fomit-frame... Maybe that´s the better solution, but what about all those without k6* archs, do they have to compile it without -fomit-frame.. when we change this, or are there smart filter-flags like "filter this when march=that"??? bye Sascha
Here's some code that would remove -fomit-frame-pointer ONLY if -march is set to a k6 type arch (i.e. k6, k6-2, k6-3). This way you can remove -fomit-frame-pointer for k6* but still let the rest of the archs use it. :) ---------- inherit flag-o-matic case `get-flag march` in k6*) filter-flags -fomit-frame-pointer ;; esac ---------- Hope that helps. :)
I am getting this error when compiling on a K6-2 with flags: -O3 -mcpu=k6-2 -march=i586 -fomit-frame-pointer -pipe The following two lines in the ebuild (either will work) are a workaround. replaceflags "-fomit-frame-pointer" "" replaceflags "-mcpu=k6-2" "-mcpu=i586" So therefore, the -mcpu flag (and not just the -march flag) can cause this bug.
*** Bug 50931 has been marked as a duplicate of this bug. ***
