gcc fails and then succeeds - definitely a problem?
On Thu, Feb 23, 2012 at 4:00 PM, Grant <email@example.com> wrote:
>>> > Parallel builds are not deterministic so if the Makefile allows a race
>>> > condition to develop it's pot luck whether you'll be hit with it or
>>> > not
>>> I got sick of stuff like that so I run MAKEOPTS="-j1" on all of my
>> If it were a frequent occurrence, there may be some benefit in that. But
>> using only one of the CPUs 8 cores is such a waste when this sort of
>> thing happens only every few weeks. Usually trying again works, rarely
>> does using -j1 make a difference and when it does a bug report ensures
>> that it won't be an issue in future.
> OK you've inspired me to give it another try. *So if I find a package
> that doesn't build with -jn where n > 1 but does build with -j1 I
> should file a bug?
Pretty much. It can get more specific than that, but that much is
already a help.
Here's the relevant portions of my MAKEOPTS and EMERGE_DEFAULT_OPTS
which should speed things up for you about as much as possible.
MAKEOPTS="--jobs --load $n" # Where $n is num_CPUs * 1.25
EMERGE_DEFAULT_OPTS="--jobs --load-average=$m" # Where $m is num_CPUs * 1.5
With the "--jobs" parameters, I haven't needed to set $n or $m to
num_CPUS*2 to try to keep the load average up.
Here's my MAKEOPTS and EMERGE_DEFAULT_OPTS verbatim, for an eight-core machine:
MAKEOPTS="--jobs --load 10"
EMERGE_DEFAULT_OPTS="--jobs --load-average=12 --verbose --tree
If you want to keep things simple, just go with num_CPUs=n for both $m and $n.