1 |
On Wed, Sep 12, 2012 at 10:55 AM, Alan McKinnon <alan.mckinnon@×××××.com>wrote: |
2 |
|
3 |
> On Wed, 12 Sep 2012 16:00:34 +0200 |
4 |
> Alex Schuster <wonko@×××××××××.org> wrote: |
5 |
> |
6 |
> > Michael Mol writes: |
7 |
> > |
8 |
> > > On Wed, Sep 12, 2012 at 9:33 AM, Neil Bothwick <neil@××××××××××.uk |
9 |
> > > <mailto:neil@××××××××××.uk>> wrote: |
10 |
> > |
11 |
> > > Instead we get, try USE="-*" :P |
12 |
> > > |
13 |
> > > "Try MAKEOPTS='-j1'" |
14 |
> > |
15 |
> > Which in fact often helps... especially for me, I am using |
16 |
> > MAKEOPTS="-j --load=4", and I often experience build problems that |
17 |
> > are not reproducible with a fixed number of jobs, regardless how |
18 |
> > large. |
19 |
> |
20 |
> Yes indeed, and that one is good advice. |
21 |
> |
22 |
> Not every Makefile out there is safe for -j > 1, so running it as one |
23 |
> job is valid debugging. It's the correct thing to do with weird build |
24 |
> failures as it tests if a specific condition is true or not. |
25 |
> |
26 |
> |
27 |
Yeah, except I've already gone that route, or otherwise ruled it out, |
28 |
before I ask. That's why it's grating. (Even more grating when I have to |
29 |
spend the time building a package again, just to convince someone that, no, |
30 |
it's not MAKEOPTS that's the problem.) |
31 |
|
32 |
It's like "Have you tried turning it off and back on again". |
33 |
|
34 |
|
35 |
> > |
36 |
> > > "Turn off distcc" |
37 |
> > |
38 |
> > "revdep-rebuild" |
39 |
> > |
40 |
> > And "emerge -e world && perl-cleaner --all && python-updater && |
41 |
> > lafilefixer --justfixit". |
42 |
> |
43 |
> Another example of proper debugging. A wise troubleshooter will first |
44 |
> verify that all relevant maintenance and consistency factors have been |
45 |
> done first before doing extensive troubleshooting. |
46 |
> |
47 |
> The last one, "lafilefixer --justfixit" is especially valuable as it |
48 |
> gets right of a huge gigantic steaming pile of crap that a) should |
49 |
> never have been there at all in the first place and b) if it's causing |
50 |
> the problem is almost impossible to pin down without lots of work. So |
51 |
> even if b) is not true, you still get the huge benefit of a) |
52 |
> |
53 |
> |
54 |
> |
55 |
> |
56 |
> |
57 |
> -- |
58 |
> Alan McKinnon |
59 |
> alan.mckinnon@×××××.com |
60 |
> |
61 |
> |
62 |
> |
63 |
|
64 |
|
65 |
-- |
66 |
:wq |