| 1 |
On 2017-10-08, R0b0t1 <r030t1@×××××.com> wrote: |
| 2 |
|
| 3 |
> Usually what happens is it will be corrupted in RAM after being |
| 4 |
> verified on disk, and faulty results will be saved to disk from RAM. A |
| 5 |
> user on the forums recently had this issue compiling dev-lang/vala, |
| 6 |
> and I have had related issues. |
| 7 |
|
| 8 |
I've had failing RAM corrupt files and cause compile failures (and |
| 9 |
various other odd problems). But, the exact symptoms tend to be pretty |
| 10 |
random. The chances are infinitesmal that a HW problem would corrupt |
| 11 |
the download (or the compile itself) in an identical manner a second |
| 12 |
time. |
| 13 |
|
| 14 |
> As for what the error means: definitions are missing, which from an |
| 15 |
> end-user perspective is not really a fixable issue. |
| 16 |
|
| 17 |
Sometimes there are external library version/use-flag requirements |
| 18 |
that don't make it into an ebuild file correctly. But, all the other |
| 19 |
cases I've run into like that yielded plenty of Google hits on the |
| 20 |
error messages. |
| 21 |
|
| 22 |
> I would rerun the compilation with -j1 if you have not already done |
| 23 |
> so. |
| 24 |
|
| 25 |
I'm going to try that as soon as chromium finishes building. |
| 26 |
|
| 27 |
> If other people can build the package then portage may be munging the |
| 28 |
> files in some way, but these issues are hard to diagnose. |
| 29 |
|
| 30 |
-- |
| 31 |
Grant |
Archives