1 |
On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <grant.b.edwards@×××××.com> wrote: |
2 |
> On 2017-10-08, R0b0t1 <r030t1@×××××.com> wrote: |
3 |
> |
4 |
>> Usually what happens is it will be corrupted in RAM after being |
5 |
>> verified on disk, and faulty results will be saved to disk from RAM. A |
6 |
>> user on the forums recently had this issue compiling dev-lang/vala, |
7 |
>> and I have had related issues. |
8 |
> |
9 |
> I've had failing RAM corrupt files and cause compile failures (and |
10 |
> various other odd problems). But, the exact symptoms tend to be pretty |
11 |
> random. The chances are infinitesmal that a HW problem would corrupt |
12 |
> the download (or the compile itself) in an identical manner a second |
13 |
> time. |
14 |
> |
15 |
|
16 |
Right, redownloading or rerunning the compilation usually fixes such |
17 |
issues. At the same time, I have seen people hit bad areas of RAM |
18 |
repeatedly and have it look like other errors. |
19 |
|
20 |
>> As for what the error means: definitions are missing, which from an |
21 |
>> end-user perspective is not really a fixable issue. |
22 |
> |
23 |
> Sometimes there are external library version/use-flag requirements |
24 |
> that don't make it into an ebuild file correctly. But, all the other |
25 |
> cases I've run into like that yielded plenty of Google hits on the |
26 |
> error messages. |
27 |
> |
28 |
|
29 |
In this case the namespace of the missing declaration is inside |
30 |
Mozilla's, e.g. it is part of Firefox or a closely bundled library. |
31 |
|
32 |
Cheers, |
33 |
R0b0t1 |