Created attachment 364214 [details] emerge --info Today i've upgrade my system to glibc-2.16.0 and found my system unusable due to Illegal instructions errors. Attached is my normal emerge --info. I used a quickpkg from another system to get back to 2.15-r3 and made some tests: If i reduce my CFLAGS to CFLAGS="-O2 -pipe -march=native -mssse3 -msse4" the output is ok. If I re-add -frecord-gcc-switches to my CFLAGS, I get illegal instructions. Maybe this is a site effect of bug #490738.
Created attachment 364216 [details] build.log with -frecord-gcc-switches
Created attachment 364218 [details] build.log without -frecord-gcc-switches
*** Bug 492920 has been marked as a duplicate of this bug. ***
Question... since this switch seems to become more popular for qa testing, there are two easy options to avoid that people kill their installation: * add something along the line of 'filter-flags -frecord-gcc-switches' in the glibc ebuilds * revert mgorny's commit to flag-o-matic.eclass that considers -frecord-gcc-switches a "safe flag" What do you think? (Yes I know it's possible to set things per package.)
FWIW, I can't reproduce this. % uname -a Linux naomi 3.12.3 #2 SMP Wed Dec 4 21:31:19 EST 2013 x86_64 AMD Phenom(tm) II X6 1055T Processor AuthenticAMD GNU/Linux % cat /var/db/pkg/sys-libs/glibc-2.17/CFLAGS -pipe -march=native -frecord-gcc-switches -Wall -g -g -O2 -fno-strict-aliasing
Filter the flag.
+ 05 Jan 2014; Mike Gilbert <floppym@gentoo.org> files/eblits/common.eblit: + Filter -frecord-gcc-switches, bug 492892.
Did anyone actually reproduce this? I can't reproduce it at all, I had no issues and see no reason to lose the valid QA warnings.
(In reply to Rick Farina (Zero_Chaos) from comment #8) > Did anyone actually reproduce this? I can't reproduce it at all, I had no > issues and see no reason to lose the valid QA warnings. A couple of people in #pentoo ran into it (DaKahuna and bill_e_ghote). That, combined with dirtyepic's endorsement, is what prompted me to add the filter. This change would only affect sys-libs/glibc; the loss of a possible warning that it is ignoring CFLAGS seems worth not breaking random systems. That said, I personally do not know why this breaks for some people and not for others.
(In reply to Mike Gilbert from comment #9) > (In reply to Rick Farina (Zero_Chaos) from comment #8) > > Did anyone actually reproduce this? I can't reproduce it at all, I had no > > issues and see no reason to lose the valid QA warnings. > > A couple of people in #pentoo ran into it (DaKahuna and bill_e_ghote). That, > combined with dirtyepic's endorsement, is what prompted me to add the filter. > > This change would only affect sys-libs/glibc; the loss of a possible warning > that it is ignoring CFLAGS seems worth not breaking random systems. > > That said, I personally do not know why this breaks for some people and not > for others. Pentoo isn't gentoo. If no one can reproduce it on a gentoo system then it's not a bug. For all we know this could be a bug in the pentoo binpkg or some other silly issue which is completely no possible to reproduce on gentoo. Don't get me wrong, I'm flattered you guys jumped up to help my users, but it is always possible that I messed up somewhere or this is an isolated incident. I would strongly encourage attempts to reproduce.
I'm leaving this up to QA and toolchain to decide whether to revert and reopen or leave it as-is.
I reproduced this bug with glibc 2.17 on Gentoo over 1 month ago.
Since Arfrever can actually reproduce I'll go with the filter for now. People who REALLY want that QA check can figure it out for themselves.
(In reply to Rick Farina (Zero_Chaos) from comment #10) > Pentoo isn't gentoo. If no one can reproduce it on a gentoo system then > it's not a bug. For all we know this could be a bug in the pentoo binpkg or > some other silly issue which is completely no possible to reproduce on > gentoo. Frankly, I don't care if you can reproduce it or not. If we have reports it's breaking systems anywhere then I'm going to fix it. I honestly don't care if you lose a couple useless QA warnings on a package where we wouldn't be able to fix them anyways.
i don't think filtering flags "fixes" the problem. i don't see a reason why using this flag would break the build.
> Pentoo isn't gentoo. If no one can reproduce it on a gentoo system then > it's not a bug. For all we know this could be a bug in the pentoo binpkg or > some other silly issue which is completely no possible to reproduce on > gentoo. My initial report was from a Gentoo system. And if i understand #c12 correctly, it's not an isolated incident. (In reply to SpanKY from comment #15) > i don't think filtering flags "fixes" the problem. i don't see a reason why > using this flag would break the build. It does, at least for me. The problem is that it *does not* break the build but spit out unusable binaries which is really bad in the case of glibc. I will try another run later.
I have emerged sys-libs/glibc-2.16.0:2.2 with -frecord-gcc-switches on a test VM with the same result. Adding the switch breaks the system due to Segmentation faults and/or Illegal instruction errors.
Created attachment 367260 [details] emerge --info without the switch
Created attachment 367262 [details] emerge --info with the switch
Created attachment 367264 [details] another build.log
This hosed a VM for me too.
OK, so fixed by filtering the flag.
