When a user sets --frecord-gcc-switches in CFLAGS portage can use it to detect if the cflags were honored, HOWEVER, in a recent bug I found that this mechanism can't work for the C++ application I was building without FF/FCFLAGS also being set. Call this an enhancement, or call it a bug fix, I'm not really sure. But this needs to be addressed somehow and the QA for the tree will improve quickly imho. I would suggest that when g++ is called to only check the CXXFLAGS not the FFCFLAGS, but I'm sure that was already considered and dropped for reasons I am not familiar with.
$(get_libdir)/portage/bin/misc-functions.sh:192 : # Check for files built without respecting *FLAGS. Note that # -frecord-gcc-switches must be in all *FLAGS variables, in # order to avoid false positive results here. # NOTE: This check must execute before prepall/prepstrip, since # prepstrip strips the .GCC.command.line sections.
(In reply to comment #1) > $(get_libdir)/portage/bin/misc-functions.sh:192 : > > # Check for files built without respecting *FLAGS. Note that > # -frecord-gcc-switches must be in all *FLAGS variables, in > # order to avoid false positive results here. > # NOTE: This check must execute before prepall/prepstrip, since > # prepstrip strips the .GCC.command.line sections. Personally I don't think every dev reads 100% of the code for portage, I certainly haven't. imho we need to either check cxxflags for c++ code (and cflags for c code etc) and eliminate this need, or put -frecord-gcc-switches into at least the dev (or to be more useful into all) profile. If this has all been discussed before feel free to point me to it and close this bug, but honestly I think a lot of devs (like me) have been trying to QA their best but simply do not know things like this. I mean it is a bit non-obvious to need to populate FFLAGS to find issues in my CXXFLAGS not being respected.
(In reply to comment #0) > I would suggest that when g++ is called to only check the CXXFLAGS not the > FFCFLAGS, but I'm sure that was already considered and dropped for reasons I > am not familiar with. Portage doesn't keep track of all the programs that are executed. It might be possible to do with sandbox or something like that though.
> Portage doesn't keep track of all the programs that are executed. It might > be possible to do with sandbox or something like that though. which is a more sane solution then? Trying to hack up something so that we can detect all this properly OR just forcing these flags on users? I know this seems a little much, but hear me out, there are lots of these bugs lurking, and forcing these flags would result in a short period of non-fatal bug reports and then a lot of fixed ebuilds... I see very little downside, and it's easy... thoughts? is there a downside to forcing -frecord-gcc-switches? none listed in the manual that I saw.
(In reply to comment #4) > thoughts? is there a downside to forcing -frecord-gcc-switches? none listed > in the manual that I saw. It's totally harmless AFAIK. The sections that it creates get stripped anyway in the strip step.
