Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 487104 - x11-libs/gtk+ changes user CFLAGS without notice
Summary: x11-libs/gtk+ changes user CFLAGS without notice
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Low enhancement (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-06 14:02 UTC by Julian Ospald
Modified: 2013-10-13 06:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Ospald 2013-10-06 14:02:56 UTC
# -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)
Comment 1 Pacho Ramos gentoo-dev 2013-10-06 14:18:39 UTC
Maybe "1" could be done at eclass level -> when replace-flags is used, make it shown the replaced flags as an einfo message
Comment 2 Julian Ospald 2013-10-06 14:20:56 UTC
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?
Comment 3 Pacho Ramos gentoo-dev 2013-10-06 14:28:23 UTC
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 :|
Comment 4 Julian Ospald 2013-10-06 14:32:31 UTC
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.
Comment 5 Julian Ospald 2013-10-06 14:33:55 UTC
also, that's rather a QA thing instead of a toolchain issue
Comment 6 Pacho Ramos gentoo-dev 2013-10-06 14:37:59 UTC
CCing QA too then (I CCed toolchain as they maintain the eclass that is providing the helpers to filter and replace flags)
Comment 7 Julian Ospald 2013-10-06 14:39:48 UTC
that's a lot of noise for such a change -.-
Comment 8 Ryan Hill (RETIRED) gentoo-dev 2013-10-06 20:39:49 UTC
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.
Comment 9 Julian Ospald 2013-10-06 20:42:27 UTC
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?
Comment 10 Julian Ospald 2013-10-06 20:47:59 UTC
(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.
Comment 11 Pacho Ramos gentoo-dev 2013-10-06 21:37:11 UTC
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
Comment 12 Julian Ospald 2013-10-06 21:48:25 UTC
(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.
Comment 13 Gilles Dartiguelongue (RETIRED) gentoo-dev 2013-10-07 07:08:03 UTC
  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.
Comment 14 Julian Ospald 2013-10-07 11:19:07 UTC
(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
Comment 15 Gilles Dartiguelongue (RETIRED) gentoo-dev 2013-10-07 11:38:38 UTC
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.
Comment 16 Julian Ospald 2013-10-07 12:18:38 UTC
(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.
Comment 17 Alexandre Rostovtsev (RETIRED) gentoo-dev 2013-10-07 15:20:59 UTC
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.
Comment 18 Julian Ospald 2013-10-07 15:41:21 UTC
I lost interest.
Comment 19 SpanKY gentoo-dev 2013-10-12 19:50:50 UTC
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
Comment 20 Julian Ospald 2013-10-12 20:09:12 UTC
(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.
Comment 21 Ryan Hill (RETIRED) gentoo-dev 2013-10-13 06:04:05 UTC
(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.