Date: Sun, 17 Oct 2010 12:55:17 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: fernando.apesteguia@gmail.com, rfarmer@predatorlabs.net Cc: freebsd-questions@freebsd.org Subject: Re: libxul compilation problem Message-ID: <201010171755.o9HHtH1N003230@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Sun Oct 17 11:46:48 2010 > Date: Sun, 17 Oct 2010 18:47:09 +0200 > From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteguia@gmail.com> > To: Rob Farmer <rfarmer@predatorlabs.net> > Cc: User Questions <freebsd-questions@freebsd.org> > Subject: Re: libxul compilation problem > > 2010/10/16 Rob Farmer <rfarmer@predatorlabs.net>: > > 2010/10/16 Fernando Apestegu=EDa <fernando.apesteguia@gmail.com>: > >> I didn't run X or whatsoever. That's why I think I should have enough me= > mory. > >> In fact after getting that error, I rebooted so I could update the > >> ports from a "fresh" > >> running system (nothing cached or so). But even in that case, I'm gettin= > g the > >> same error. > >> > >> Any VM tuning I can try? > > > > I'm not really knowledgeable about that kind of thing. > > > > However, the port is marked MAKE_JOBS_SAFE which means that it will > > try to run multiple compiler instances in parallel, to speed things up > > if you have multiple CPUs/cores. You can try running with "make > > -DDISABLE_MAKE_JOBS" to just run one at a time - maybe you have enough > > memory for that but not multiple jobs at once? > > Hi Rob, > > The machine has one single core cpu. Finally I was able to compile the > thing, compiling > the offending file by hand (nsHtml5ElementName.cpp) without the -O2 > optimization flag. > With this flag, cc1plus eats up all the memory of my system in a few > seconds. Without > the flag, the file is compiled without any problems and quite fast. > > Should this issue be a candidate for filing a PR? *ONLY* if you can provide a 'fix' _with_ the report! <grin> (Make sure the fix works on a machine with only 64mb ram and 256m swap. ) Turning on optimization virtually _always_ results in the compiler needing more resources. "How much" more depends on the size, complexity, and ' optimizability' of the code being compiled. The "simple" fix for your problem is to add swap space to the system. swap space does -not- have to be in a dedicated partition, see 'man swapon' for how to use a -file- as temporary swap space. Note: if you find someting that won't compile, given a combined 4 gigs of RAM and swap space, and the build isthe only thing running beyond core system services, *then* you've got the basis for 'good' PR filing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010171755.o9HHtH1N003230>