[blfs-dev] Resources for qtwebengine

Thomas Trepl thomas at linuxfromscratch.org
Wed Dec 13 09:53:14 PST 2017

Am Mittwoch, den 13.12.2017, 17:08 +0000 schrieb Ken Moffat:
> On Wed, Dec 13, 2017 at 10:07:07AM -0600, Bruce Dubbs wrote:
> > Thomas Trepl wrote:
> > > Am 2017-12-13 13:39, schrieb Thomas Trepl:
> > > > hi all,
> > > > 
> > > > I'm currently trying to compile version 5.10 but it seems my
> > > > machine
> > > > is too small. It is a VBox-VM with 2GB RAM, 2GB swap partition
> > > > but
> > > > compilation failed with "virtual memory exhausted". I increased
> > > > the
> > > > mem to 3 GB but it looks like the process runs in same
> > > > situation
> > > > (currently at 13957/21739 targets to compile).
> > > > 
> I think such a small system will have pains with several large
> desktop packages.  I haven't built in a VM in ages, but on my i3
> (4GB RAM, 3.75GB available) and my A10 Kaveri (8GB RAM but < 7GB
> available) building qtwebengine is unpleasant.
Yes, its not that highly equipped. Looks like I have to tweak the VM
settings a bit. I just wanted to hear your opinions whether tis config
is indeed to small and such monsters of packages to require a better
equipped machine.
> How do the 4 CPUs compare to what your host system offers ?  My
> impression has always been that *qemu* will not map CPUs 1:1 (there
> is an overhead of running a VM) and for a big package that DOES make
> a difference.  But I have no idea about vmware.
The physical box is a 16GB E3-1245 Xeon, showing 8 CPUs to the system.
Sure, there is a bit of difference from VM compared to physical, but
the system at all is that fast that I do not worry about.

> Also: qtwebengine, at least until 5.9, has used its included ninja
> if there is no system version.  And ninja spawns N+2 jobs if more
> than 2 CPUs.  For system ninja we have Bruce's patch to use an ENVVAR
> to limit the number of jobs.  Limiting the number of jobs might help
> in a VM or anywhere else short of memory - these are not trivial
> 'build some little C file' jobs, these are "throw a kitchen-sink of
> headers at this complex C++ code" jobs.
Ah yes, the note in the BLFS book that ninja will use all available
cpus made me forget that Bruce has created that patch to address that.
Will try it - for this package it seems to make really sense.

@Bruce, thanks for the patch!

> If you only have 4 (real) cores, using -j6 on large C++ files is
> unlikely to help - it might hinder, it might not make a lot of
> difference.
Well, i configured my VM to have 4 CPUs as many of the BLFS packages
has a SBU number with a note like "XX SBU (using 4 cores)". So i made 4
CPUs visible. 

> For a clean build, ninja has few benefits.  In cmake packages it is
> marginally faster than the Makefiles cmake produces, but only a
> little.  The benefit is for developers who (re) build in a dirty
> tree after making a minor change.  In that situation Makefiles
> created by cmake can do a lot of work, good Makefiles from
> autotools, and ninja files, will just check what needs to be
> rebuilt.

Thanks Ken and Bruce for the comments so far!

More information about the blfs-dev mailing list