# -O3 and company cause random crashes in applications. Bug #133469 replace-flags -O3 -O2 strip-flags I don't like ebuilds doing such stuff without telling me. I see two solutions: 1) just print an ewarn/einfo whatever in pkg_setup or pkg_postinst 2) make those 2 lines depending on a "custom-cflags" useflag and _mask_ that useflag (I prefer this)
Maybe "1" could be done at eclass level -> when replace-flags is used, make it shown the replaced flags as an einfo message
I think custom-cflags should be exposed to the user which also enables him to do testing. When was the last time -O3 was actually tested?
I don't really like the idea of letting people to take so much risk behind a custom-cflags USE flag, we could get a crash report in a gtk+ app and would be difficult to know it is caused by gtk+ being compiled with -O3 I would wait for other team members opinion, but I also think this should be discussed more globally as this isn't a gtk+ issue -> there are a lot of ebuilds filtering -O3, -ffast-math... that would also be covered by this For now, will CC flag-o-matic.eclass maintainers to let them know and suggest any other idea :|
As I said... that useflag will be MASKED... so you will know when a user has compiled it with -O3. I do not see a problem there.
also, that's rather a QA thing instead of a toolchain issue
CCing QA too then (I CCed toolchain as they maintain the eclass that is providing the helpers to filter and replace flags)
that's a lot of noise for such a change -.-
If you've had issues in the past with -O3 then it is perfectly acceptable for you to restrict that flag. We don't provide USE flags to enable stuff that we know doesn't work. We don't print anything because it always turns into people whining about how their flags are being ignored and how Gentoo is about Choice(tm) and that it's impossible that those flags break things because they've used them for 17 years and have NEVER had a problem, etc etc. IMO it's fine the way it is.
sure, but that's not an argument against "custom-cflags" useflag which I am requesting here. Also, my question remains: when was the last time -O3 was tested?
(In reply to Ryan Hill from comment #8) > We don't provide USE flags to enable stuff > that we know doesn't work. > Hm, base-system does that.
I disagree with handling this with custom-cflags *only* for this package -> we need to discuss at first what kind of stiff we want to put behind the "custom-cflags" USE flags to have some consistency in the tree regarding the sense of this USE flag
(In reply to Pacho Ramos from comment #11) > I disagree with handling this with custom-cflags *only* for this package -> > we need to discuss at first what kind of stiff we want to put behind the > "custom-cflags" USE flags to have some consistency in the tree regarding the > sense of this USE flag There is no consistency. This is a maintainer decision.
08 Oct 2002; foser <foser@gentoo.org> gtk+-2.0.6-r1.ebuild : Replace -O3 with -O2 to be on the safe side (bug 8762) and yes, it caused hard to find bugs. Those bugs can be triggered by manually adding some individual cflags automatically enabled by -O3 but I'd rather have gtk+ being "slow" and known to work than experience random application segfaults like what happened back then. I remember that bug in gtk+-2.8, my system was built -O3 (yeah I was young), and pidgin would segfault everynow and then without a noticeable pattern of action. It was driving me crazy until I found that report about -O3 breaking some applications and getting it fixed. As you can see, it was at least the second time -O3 was filtered from the ebuild. On the other side, it's been years we've been teaching our users that they must rebuild with -O2 and safe cflags when they hit a bug just to be sure, but it is unlikely that they would systematically rebuild all rdepends.
(In reply to Gilles Dartiguelongue from comment #13) > 08 Oct 2002; foser <foser@gentoo.org> gtk+-2.0.6-r1.ebuild : > Replace -O3 with -O2 to be on the safe side (bug 8762) > > and yes, it caused hard to find bugs. Those bugs can be triggered by > manually adding some individual cflags automatically enabled by -O3 but I'd > rather have gtk+ being "slow" and known to work than experience random > application segfaults like what happened back then. > > I remember that bug in gtk+-2.8, my system was built -O3 (yeah I was young), > and pidgin would segfault everynow and then without a noticeable pattern of > action. It was driving me crazy until I found that report about -O3 breaking > some applications and getting it fixed. As you can see, it was at least the > second time -O3 was filtered from the ebuild. I still do not see a counter-argument. You could ask the user for a build log of gtk+ and see "custom-cflags" enabled there right at the top. That's what other packages do as well like firefox, thunderbird, xen, zfs, libsdl2... Also mind that "stip-flags" does more than just filtering -O3. By masking it, you make it even more clear that this is unsupported. Unsupported useflags are allowed (if masked). We have a policy for that which was reviewed by QA. In the end, this is still a maintainer decision and has to be decided per-package. This is not a global issue. http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=blobdiff;f=ebuild-writing/common-mistakes/text.xml;h=3663eeade3518b3197e6a2662963059eaf1e12fb;hp=549cb00c2d318f83d3e570498d95692ef8495e9d;hb=4eb1dc77d0de1e3902ff5887fddc93129bc4d3e4;hpb=f4121175e9bc0d0260bbe399ef39339085afa481
You don't seem to understand that this triggers bugs in leaf packages, not gtk+ itself. And they are hard to trace back to gtk (or so I remember). We are very-well aware that strip-flags does more that just -O3 -> -O2 but this is an assumed choice for having a safe gtk+ rather that hypothetical optimizations.
(In reply to Gilles Dartiguelongue from comment #15) > You don't seem to understand that this triggers bugs in leaf packages, not > gtk+ itself. And they are hard to trace back to gtk (or so I remember). > Sure I do and this is the same as in libsdl/libsdl2. > We are very-well aware that strip-flags does more that just -O3 -> -O2 but > this is an assumed choice for having a safe gtk+ rather that hypothetical > optimizations. So make a decision.
Why are we arguing about the number of angels on a pinhead? The only way to resolve this issue is TESTING. Julian, if you are interested in gtk+ with -O3, please remove the replace-flags from gtk+ ebuilds in your local overlay, rebuild them with -O3, and run a wide variety of gtk+ applications for a week or so. I would suggest a regular gnome-3.8 desktop, plus a variety of big gtk+-2 stuff like firefox, chromium, gimp, inkscape, pidgin, etc. If you don't get suspicious segfaults, then it would make sense to add a custom-flags to IUSE. If you do - well, Gentoo allows a variety of reasonable choice, and sometimes some choices can have bad side effects as well as good ones, but we must not allow a choice whose *main* effect is random crashes.
I lost interest.
from base-system/toolchain perspective, gtk ebuild seems to be doing things reasonably. there is no standard wrt USE=custom-cflags ... we leave that up to the maintainer. we also don't package.use mask that flag as it's generally understood that it's your problem if you use it. if the maintainer thinks the hardship is way too much (like gtk messing up way too many packages), then it's their call to not even provide USE=custom-cflags. i've updated flag-o-matic so that when strip-flags runs and does make a change, it issues an einfo: http://sources.gentoo.org/eclass/flag-o-matic.eclass?r1=1.189&r2=1.190
(In reply to SpanKY from comment #19) > we also don't package.use mask that flag as it's > generally understood that it's your problem if you use it. That may be your personal opinion, but is not what QA advises or what the policy in the devmanual says. Unsupported useflags have to be masked.
(In reply to Julian Ospald (hasufell) from comment #20) > That may be your personal opinion, but is not what QA advises or what the > policy in the devmanual says. > > Unsupported useflags have to be masked. Not really. There are tons of examples of this in the tree. custom-cflags is for when situations where upstream insists you build with their flags, possibly ignoring bug reports if you don't (eg. firefox), or if there is a history of user flags breaking a package but nothing specific that a maintainer could filter out (either it changes with different compiler versions, or only with certain combinations of flags and it isn't practical to test them all). Otherwise we should always honour user flags except in places where we know they break things. Back on topic - it should be okay to stop stripping -O3 on gtk+. In bug #133469 it says it was added for gcc-4.1, which IIRC had some wrong-code bugs at -O3.
