I modified the ebuild of Ooo 2.3.1-r1 to remove the lines - filter-flags "-O[s2-9]" and it compiled fine in my case, thus I suggest a custom-optimization use which will compile with the optimization as stated in make.conf. Reproducible: Always Steps to Reproduce:
I am playing with the same thought, do a safe build where flags are filtered completely. For the majority that just want it to complete. And for the rice cookies, add a flag to let it optimize, surely unsupported and easier to identify for the maintainer, if there was evil gcc flags involved. Remember, there were cases where the code was silently miscompiled. That is hardly possible to maintain. JFYI, the build environment adds '-O2' where appropriate and linker flags that do safe optimizations. And I bet they will add gcc graphite support to the modules that do improve by that. If the LO developers do not add that on their own, I will start a thread on the mailing list, asking for its usefulness. ;)
You may set the custom-optimization to - by default.
A nice example of wasting resources is bug 345799. And we have had some more of these in the past. ;) And what may come in the future. Sorry to annoy, but ...
Maybe an ewarn can be added.
There is an ewarn about lowering flags if it fails. It is just ignored.
Then how about using read to prompt user input? Using -custum-optimization (in EAPI3) is good enough. It can be even masked.
As we are going to deprecate openoffice not going to do this. But there's already a bug for libreoffice, so head over there ;-) bug #355981
(In reply to comment #7) > As we are going to deprecate openoffice not going to do this. But there's > already a bug for libreoffice, so head over there ;-) > > bug #355981 Are you sure? Are you even gonna remove the bin package? A lot of people need that for testing.
(In reply to comment #8) > (In reply to comment #7) > > As we are going to deprecate openoffice not going to do this. But there's > > already a bug for libreoffice, so head over there ;-) > > > > bug #355981 > > Are you sure? Are you even gonna remove the bin package? A lot of people need > that for testing. Yes I'm sure. We didn't have a vanilla app-office/openoffice in the tree for years, libreoffice is the direct successor to what we had before in the OOo-package. And vanilla OOo is a real pain to build / maintain, basically would be a totally new package. openoffice-bin on the other hand is going to stay for now. But that's all very much off-topic here.
