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

Bruce Dubbs bruce.dubbs at gmail.com
Sun Aug 18 11:00:04 PDT 2013

Fernando de Oliveira wrote:
> 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.

Hmm.  I do note that Xulrunner says you need 5G of disk space.  I guess 
I didn't notice the RAM requirement since I have 10G or ram on my 
development system.  There are a few packages in BLFS that are very big:

openjdk-buildsize     9.2 GB
gcc-buildsize         6.2 GB
JS-buildsize          1.2 GB
wireshark-buildsize   1.1 GB
texlive-buildsize     1.6 GB
qt4-buildsize         1.9 GB
qt5-buildsize         2.5 GB
xulrunner-buildsize   4.9 GB
firefox-buildsize     4.9 GB
seamonkey-buildsize   1.6 GB
AbiWord-buildsize     1.8 GB
libreoffice-buildsize 6.1 GB
thunderbird-buildsize 3.1 GB
inkscape-buildsize    2.0 GB

I would want at least 2G of RAM for any of these.

It's interesting that seamonkey is so much smaller than ff or tb.

   -- Bruce

More information about the blfs-dev mailing list