2011/10/6 Radek Doulík <rodo@novell.com>:
Hi,
I would also vote for not reverting stuff (at least not before we try
fix it first), when only some of the tinderboxes fail due low system
resources.
my mac as 32 GB of memory and a dual quad core...
the linux box as 8GB and a signle quad...
'low system ressource' is _not_ the problem here.
most likely a gcc corner-case...
I will try to split the offending source file to few smaller files,
similar to what we do for some non-generated CXX sources, and push
again.
One thing I noticed. It might be useful to run tinderboxes without gcc
optimization (ie. with -O0). It makes huge difference in compile time -
more than 10 times faster on my system and could make the tinderbox
turnaround much faster.
Yes, but the generated daily build would be less usefull that way and
possibly hide optimisation-induced bug until the last minute.
customshapepreset.cxx compiled with -O2
real 4m22.910s
user 4m13.794s
sys 0m9.996s
The mac version did not finished it died afeter 20+minutes
The linux one I killed after the gcc process went up to 7+GB of ram
used and the machine was becoming unresponsive (swapping like hell)
customshapepreset.cxx compiled with -O0
real 0m25.427s
user 0m25.242s
sys 0m1.035s
note : if for that/these source -O is not necessary or useful then you
can tell the build to do a NOOPT compile. see sd/Library_sd.mk for an
example.
Norbert
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.