On Wednesday 07 July 2010 10:53:43 littlebat wrote:
> On Wed, 07 Jul 2010 13:31:32 +0100
>
> Andrew Benton <[email protected]> wrote:
> > On 07/07/10 12:10, littlebat wrote:
> > > So, I need some accurate answers:
> > > 1, Can we build LFS with parallel compiling through the book?
> >
> > Yes. A few packages won't build in parallel (openssl) and some
> > packages sometimes fail to compile with a parallel build (xmlto) but
> > pretty much everything else is fine with make -j$NUMBER
> >
> > > 2, Can we build Chapter 5 with parallel compiling but do not use
> > > parallel compiling in the rest Chapters (includes Chapter 6 and
> > > Chapter 8)?
> >
> > I use make -j4 all the time. Doesn't give me any problems. I've had
> > some problems in the past with "make -j4 install" not installing all
> > of glibc's files so I now avoid installing in parallel. "make
> > install" is mostly limited by disc input/output so I see no benefit
> > in "make -j4 install". Consequently I don't set MAKEFLAGS as it risks
> > breaking "make install" for little benefit.
>
> Maybe I am lucky:-), I set MAKEFLAGS='-j 2' on my E7400 double cores
> CPU, no any exception appeared until I finished all the packages in
> Chapter 5. But, I think this should depends on the quality of the
> package itself. Maybe, after the next release of a package, it will
> refuse to do a parallel make or parallel make install just like you have
> experienced.

Many packages must be configured and installed in uni-processor mode. I've 
found a *few* packages that must be built in uni-processor mode, such as 
groff, net-tools and snort.

On a quad-core system, '-j 4' really only shines when building glibc, gcc and 
the kernel. There aren't many other packages that are truly large enough to 
benefit.

The great limiter today is './configure'; it is slow. Some packages take 3 
minutes to configure, and 5 seconds to compile. Aside, I think 
the ./configure mechanism needs to be reimplemented with significant 
paralelism.

The admonition against building multiple packages in parallel exists because 
dependencies *among* packages are not identified; LFS is a 'follow these 
steps EXACTLY and you'll have no trouble' program :). If you go to the 
trouble to identify the interpackage dependecies and ensure that you build 
packages in the correct dependent order, there's no reason you couldn't build 
5-10 packages simultaneously.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to