1 |
On Sun, 28 Oct 2007 19:40:01 +0200 |
2 |
"Yoav Luft" <yoav.luft@×××××.com> wrote: |
3 |
|
4 |
> On 10/28/07, Dan Farrell <dan@×××××××××.cx> wrote: |
5 |
> > |
6 |
> > On Sun, 28 Oct 2007 06:04:43 +0200 |
7 |
> > "Yoav Luft" <yoav.luft@×××××.com> wrote: |
8 |
> > |
9 |
> > > hello, |
10 |
> > > during an emerge -uDN process, the compilation for gcc-4.2.1 |
11 |
> > > failed, as well as for glibc, with same errors. |
12 |
> > > I have run revdep-rebuilt, and found out about a broken |
13 |
> > > libexpat.so.0thingy, which I solved following the instruction of |
14 |
> > > the gentoo irc bot. |
15 |
> > > after that, compiling gcc still fails. |
16 |
> > > |
17 |
> > > insn-emit.c: In function 'gen_leave': |
18 |
> > > insn-emit.c:1123: internal compiler error: Segmentation fault |
19 |
> > > . . . |
20 |
> > > I'm clueless about it, but do feel that not being able to updaate |
21 |
> > > gcc or glibc is bad, and will probably mean that I will not be |
22 |
> > > able to update other things as well. |
23 |
> > |
24 |
> > Have you done a memtest-86, and waited for a few days, or at least a |
25 |
> > few error-free complete passes? |
26 |
> > -- |
27 |
> > gentoo-user@g.o mailing list |
28 |
> > |
29 |
> > |
30 |
> |
31 |
> I have waited for a few days, and tried different versions of gcc and |
32 |
> glibc, all failed. |
33 |
|
34 |
did you remember to emerge --sync, maybe even emerge --metadata ? |
35 |
frankly, I am not sure what the last one does, but I believe it could |
36 |
update data concerning the ebuilds themselves, which could be a |
37 |
potential source of problems. |
38 |
|
39 |
> I did had an overheating problem a couple of months ago, right around |
40 |
> the time the problem started. So, it could be that the CPU is |
41 |
> semi-toasted? How do I run memtest-86? |
42 |
|
43 |
there are 2 ways I know of: |
44 |
1) simply reboot on a gentoo boot cd and type 'memtest' or some such |
45 |
at the boot: line. (Refer to the on-disc documentation for help |
46 |
concerning what exactly to type) |
47 |
2) a)emerge memtest86+; |
48 |
b) find memtest.bin and move it to /boot/memtest86plus |
49 |
c)add a grub line that looks like this: |
50 |
title=Memtest86Plus |
51 |
root (hd0,1) # this refers to my boot partition. you may have |
52 |
# to change this setting. |
53 |
kernel /boot/memtest86plus/memtest.bin |
54 |
d) reboot and use memtest from the hard drive. |
55 |
|
56 |
If, when you emerge memtest86+, you have /boot mounted, the emerge will |
57 |
plop the .bin file down right where it needs to be. If not, the output |
58 |
from the emerge should giveyou the info you need. |
59 |
|
60 |
Of course, memtest.bin doesn't have to be on your boot partition, if |
61 |
grub can read the root partition. In fact, you might not even have |
62 |
a /boot partition. Just make sure the root line for memtest in grub is |
63 |
proper. |
64 |
|
65 |
|
66 |
> Is there anything else that's |
67 |
> worth checking? |
68 |
|
69 |
You could try a CPU stress test. If the cpu isn't working properly, |
70 |
using it at 100% capacity for a little while ought to make that |
71 |
apparent. But your results may vary. A rudimentary query on google |
72 |
points me in the direction of: |
73 |
|
74 |
http://users.bigpond.net.au/cpuburn/ |
75 |
|
76 |
However, i don't know if it's source and if not, there's always a valid |
77 |
security concern when running others' binaries. something to keep in |
78 |
mind... |
79 |
-- |
80 |
gentoo-user@g.o mailing list |