libxul compilation problem

Fernando Apesteguía fernando.apesteguia at gmail.com
Mon Oct 18 06:25:22 UTC 2010


On Sun, Oct 17, 2010 at 7:55 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>> From owner-freebsd-questions at 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 at gmail.com>
>> To: Rob Farmer <rfarmer at predatorlabs.net>
>> Cc: User Questions <freebsd-questions at freebsd.org>
>> Subject: Re: libxul compilation problem
>>
>> 2010/10/16 Rob Farmer <rfarmer at predatorlabs.net>:
>> > 2010/10/16 Fernando Apestegu=EDa <fernando.apesteguia at 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. )

Hehe, OK, I'll try to have a look at it.

>
> 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.

I had done it if disabling the optimization wouldn't have changed anything. The
main problem was that I didn't know how much swap I had to add.
Right now I have an updated system but I will have a look at how much RAM
this takes using -O2.

>
>
> 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.

Thanks!

>
>
>


More information about the freebsd-questions mailing list