FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 02-23-2012, 08:27 PM
Alex Schuster
 
Default gcc fails and then succeeds - definitely a problem?

Grant writes:

> I have a 1200 watt Corsair power supply and my temps are very low even
> during the stress test so I'm thinking bad (Corsair) RAM. I should
> remove modules one at a time and re-test to narrow it down?

This sounds just like the right thing to do. Well, if you have four RAM
chips, remove two at once to speed up the diagnosis.

Wonko
 
Old 02-23-2012, 08:37 PM
Alan McKinnon
 
Default gcc fails and then succeeds - definitely a problem?

On Thu, 23 Feb 2012 11:46:03 -0800
Mark Knecht <markknecht@gmail.com> wrote:

> > Whenever I get build failures with the load-adaptive MAKEOPTS and
> > EMERGE_DEFAULT_OPTS, I check the build log to see if it's relatively
> > obvious that something was depended upon before it was built. If
> > so, I file a bug.
> >
> > Happens every month or so, for me.
> >
>
> There are log files? You're telling me I should read them? Gawd,
> pretty soon you're gonna try to make a real admin of me instead of
> just the oblivious happy home user that I am... ;-)

<sideways compliment>

Well, we wouldn't mention log files if we didn't feel you made the grade

:-)

</sideways compliment>


--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 02-23-2012, 09:05 PM
Michael Mol
 
Default gcc fails and then succeeds - definitely a problem?

On Thu, Feb 23, 2012 at 4:00 PM, Grant <emailgrant@gmail.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
>>> systems.
>>
>> 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
--with-bdeps=y --keep-going"

If you want to keep things simple, just go with num_CPUs=n for both $m and $n.

--
:wq
 

Thread Tools




All times are GMT. The time now is 12:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org