Just noticed this today, I was trying to upgrade to www-client/chromium-17.0.928.0 and it would fail when building sqlite.o, but then I remembered when I was attempting to emerge sqlite ages ago with the -ffast-math cflag that it would refuse to build with it because it would break it, so a warning, or a complete refusal to build with -ffast-math should probably be added. Reproducible: Always Steps to Reproduce: 1.Attempt to compile chromium with -ffast-math cflag 2.Let it build until it fails at sqlite.o Actual Results: Emerging fails at the compiling of sqlite.o Expected Results: A warning or refusal to emerge chromium with -ffast-math
By the way, I don't really know if this is something I should be reporting as a bug, I more than know it's stupid to have ffast-math as a cflag (it was only being used globally since I forgot to remove it) but a warning/refusal to build comes up when you build dev-db/sqlite with ffast-math so I would think it should also come up here when building the internal sqlite for chromium. I'm pretty new to bug reporting (if you couldn't already tell :p) so sorry if this isn't justified, as aforementioned I noticed it happens with other packages so should probably happen with chromium.
Working on a fix.
Certainly no harm in filtering it but it is worth nothing that probably 90% of the packages in the tree will suffer from this same "bug" - as you've already noted it isn't really something that should go in CFLAGS except on a per-package (or more likely per-file) basis.
Fixed without revbump. Used strip-flags.
Why not filter-flags instead? Last I checked chromium had no problems with -O3 or graphite flags. BTW, v8 with -ffast-math builds but crashes predictably in certain situations as well.
We don't want to play whack-a-mole with compiler flags.
(In reply to comment #6) > We don't want to play whack-a-mole with compiler flags. I'm not a big fan of strip-flags in general - it seems contrary to the nature of Gentoo. If I build a package with complicated CFLAGS and run into problems then I build it without complicated CFLAGS. I think that it is generally accepted that bugs can be closed as invalid when reported with crazy CFLAGS so you don't need to try to filter them all. Users will file invalid bugs no matter what you put in the ebuild, so why punish users who know what they're doing? On the other hand, I see that the two flags that I would point out as being safe are apparently now bundled in -O2 anyway.
(In reply to comment #7) I don't really feel strongly about this either way. Paweł is the one that needs convincing. I generally prefer to let people shoot themselves in the foot, so long as they are warned.
In case someone cares enough, here's the nasty bashrc hack I use to set arbitrary flags on Chromium. Obviously not guaranteed to work in the future (exploit redefining a function currently called after the strip-flags). e.g: reset graphite and switch to -O3. if [[ $CATEGORY == www-client && $PN == chromium ]]; then pre_src_configure() { egyp() { replace-flags '-O2' '-O3' append-flags '-floop-interchange' '-floop-strip-mine' '-floop-block' local -a cmd=( 'build/gyp_chromium' '--depth=.' "${@}" ) printf '<%q> ' "${cmd[@]}" >&2 "${cmd[@]}" } } fi
Ok, since we clearly have some determined people who want to live dangerously, I have added a custom-cflags USE flag that will prevent the replace-flags and strip flags functions from being called. You will find it on the latest dev channel and live ebuilds. On the dev side, this should be better than trying to troubleshoot random bashrc hooks.
