On Wed, Sep 12, 2012 at 10:55 AM, Alan McKinnon <alan.mckin...@gmail.com>wrote:
> On Wed, 12 Sep 2012 16:00:34 +0200 > Alex Schuster <wo...@wonkology.org> wrote: > > > Michael Mol writes: > > > > > On Wed, Sep 12, 2012 at 9:33 AM, Neil Bothwick <n...@digimed.co.uk > > > <mailto:n...@digimed.co.uk>> wrote: > > > > > Instead we get, try USE="-*" :P > > > > > > "Try MAKEOPTS='-j1'" > > > > Which in fact often helps... especially for me, I am using > > MAKEOPTS="-j --load=4", and I often experience build problems that > > are not reproducible with a fixed number of jobs, regardless how > > large. > > Yes indeed, and that one is good advice. > > Not every Makefile out there is safe for -j > 1, so running it as one > job is valid debugging. It's the correct thing to do with weird build > failures as it tests if a specific condition is true or not. > > Yeah, except I've already gone that route, or otherwise ruled it out, before I ask. That's why it's grating. (Even more grating when I have to spend the time building a package again, just to convince someone that, no, it's not MAKEOPTS that's the problem.) It's like "Have you tried turning it off and back on again". > > > > > "Turn off distcc" > > > > "revdep-rebuild" > > > > And "emerge -e world && perl-cleaner --all && python-updater && > > lafilefixer --justfixit". > > Another example of proper debugging. A wise troubleshooter will first > verify that all relevant maintenance and consistency factors have been > done first before doing extensive troubleshooting. > > The last one, "lafilefixer --justfixit" is especially valuable as it > gets right of a huge gigantic steaming pile of crap that a) should > never have been there at all in the first place and b) if it's causing > the problem is almost impossible to pin down without lots of work. So > even if b) is not true, you still get the huge benefit of a) > > > > > > -- > Alan McKinnon > alan.mckin...@gmail.com > > > -- :wq
