2011/10/6 Radek Doulík <r...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
