libreoffice with O2, graphite (GCC) builds fine. Thus there should be a custom-optimization flag (which can be hard masked) to not strip CFLAGS. Reproducible: Always Steps to Reproduce:
For reference see bug #345379, where we had this discussion about openoffice. But I agree: We should do that, if someone delivers a patch it might come sooner ;-)
Patch? What for?
(In reply to comment #2) > Patch? What for? For implementing this in the ebuild with sane defaults for LibreOffice which won't break.
Apparently it doesn't. I removed the Os-O3 filter flags; that too I was compiling with graphite. Many people have the same reports... you should too try it out. For me it has never failed.
(In reply to comment #4) > Apparently it doesn't. I removed the Os-O3 filter flags; that too I was > compiling with graphite. Many people have the same reports... you should too > try it out. > > For me it has never failed. Anecdotal evidence from one user is not a very convincing argument against the hundreds of build failures in regard to over-optimization you can find in the bug database ;-) And we are not talking about ONE specific optimization. So: We still need sane defaults, that said this doesn't mean they have to be the same as now, but they simply shouldn't break stuff....
@Andreas You are always free to look at my eclass. ;) I handle useflag custom-cflags with sane defaults. http://code.google.com/p/gekis-playground/source/browse/trunk/eclass/libreoffice.eclass
(In reply to comment #6) > @Andreas > You are always free to look at my eclass. ;) > I handle useflag custom-cflags with sane defaults. > > http://code.google.com/p/gekis-playground/source/browse/trunk/eclass/libreoffice.eclass Nice :-) Could you maybe explain a bit how you decided on those defaults? Cause they differ a bit from what have now (for instance the gcc<4 case seems not to be covered)
I took them from eclass flag-o-matic minus -g* flags for bug 345799. I have an experimental version where I am free to ignore such crufty compilers. LibreOffice adds c++11 (c++0x) code already. So <=gcc-4.5 may rest in peace in the near future(i.e., addition of nullptr type, hopefully). You may still add the check of these compilers for that flags. Otherwise, if the user seems to know better, let the rice cookie fail and give a damn(notice) like other packages already do. ;)
I think you should hard mask the custom-optimization use. Alternatively, the custom-optimization use will be unset by default.
(In reply to comment #8) > I took them from eclass flag-o-matic minus -g* flags for bug 345799. I have an > experimental version where I am free to ignore such crufty compilers. > LibreOffice adds c++11 (c++0x) code already. So <=gcc-4.5 may rest in peace in > the near future(i.e., addition of nullptr type, hopefully). Yeah, I've seen that. But in comparison to the flag-o-matic eclass you seem to have removed a lot of other stuff, like -fno-strict-overflow, -fno-PIE -fno-pie -fno-unit-at-a-time and so on. (also the whole block in the eclass after that) Any rationale for that? Also if I have you around: What was the reason again for stripping -O*? It's been quite some time since I looked at all this compiler stuff and obviously I seem to forget pretty quickly... So some clearing up would be pretty much appreciated...
Yes, I would like to see flag-o-matic updated for optionally allowing/stripping debugging flags like -g. Then I would not have to set ALLOWED_FLAGS. I just do not want to copy the big blob. Hmm, maybe a 'strip-flags' followed by a conditional 'filter-flags -g*' could do as an workaround ... I will change that. We strip '-O*' simply because of silent miscompiles. LO/OOo adds -O2/1/0 where appropriate.
This is now fixed in 3.3.2_rc2. Thanks Hanno for all the help & advice. Closing.
Thanks. I don't have to modify ebuilds now.
