[blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1

Fernando de Oliveira famobr at yahoo.com.br
Sun Aug 18 09:22:10 PDT 2013

Em 18-08-2013 11:06, Bruce Dubbs escreveu:
> BLFS Trac wrote:
>> #3982: Firefox-23.0.1/Xulrunner-23.0.1
>>   * resolution:   => fixed
>> Comment:
>>   Fixed at revision 11650.
>>   Xulrunner, the first I built, needed over 3.3GB of memory, and ld died.
>>   Had to increase memory.
> Memory or disk space?  I wouldn't think anything needs 3.3G RAM to compile.
>    -- Bruce

Perhaps disk space, but not partition space, I believe. If it was not
this problem, I would have commited much earlier, still on the 17th,
same day of release.

First, build died repeatedly at the same point (attached, all five VMs
are at this stuck point, now, it was lucky, hope I copied/pasted it
correctly). Then, I follow disk/memory usage, and very rapidly, RAM and
swap were 100% full, and the command taking more meory, called probably
by that python script - or is it called python program? I cannot open
the machine where it occurred to see, other three VMs are building
xulrunner, now.

A message of ld dead, Error 9, sent me in the internet to errors related
to not enough swap. It was a VM, so, it was easier to increase the RAM
than increase the 1.5GB swap. I increased RAM to 4GB, followed with htop
through ssh in a tablet, and at sometime, it was using 3.3GB of RAM,
swap not used anymore. Left it there, and later, it had finally
completed. With these observations, I called "memory", instead of
talking about RAM or swap. Other reason to increase the RAM, not swap,
is that, obviously, a process taking place in RAM should be faster than
in disk.

It could be something wrong with that machine (only lfs x86_64 I have).

Sometime ago (perhaps a couple of years), I followed these mozilla
applications (SeaMonkey included), because one day, what was a
reasonably fast compile/link, suddenly became increasingly very slow,
from one version to the next, and discovered that was at this same point
of the attached command. I think it is were libxul is linked. Some of
the machines started to become unresponsive during that command, so I
increased the 1GB RAM to 1.5GB, long ago, and things got better. One
thing I am sure, each new version of these programs, more memory and
time are needed. In my old days of FORTRAN, when compile and link were
clearly separated, I would be sure, but these days, I am still
struggling to understand these things.

The VMS running now have 1.5GB of RAM, in this host, and two others, in
another host, only have 1.0GB, running now, too. Since these problems
started, I keep the VMs at the login, no X, and use ssh, to increase
available RAM.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xulrunner-23.0.1-command-very-slow.log
Type: text/x-log
Size: 3467 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-dev/attachments/20130818/136027f4/attachment.bin>

More information about the blfs-dev mailing list