Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo User (http://www.linux-archive.org/gentoo-user/)
-   -   gcc fails and then succeeds - definitely a problem? (http://www.linux-archive.org/gentoo-user/636789-gcc-fails-then-succeeds-definitely-problem.html)

Alex Schuster 02-23-2012 08:27 PM

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

Alan McKinnon 02-23-2012 08:37 PM

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

Michael Mol 02-23-2012 09:05 PM

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


All times are GMT. The time now is 11:45 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.