tracking down the source of compilation trouble

[Timothy A. Seufert]

At 7:33 AM -0500 2/16/00, R Shapiro wrote:
>Timothy A. Seufert writes:
>  > Hardware problems.  Running a very large build (such as the kernel or
>  > xemacs) is often a good way to smoke out flaky hardware.
>
>Hmm, it's possible, I have had odd behavior occasionally on the 7500.
>Otoh I wouldn't expect this kind of problem to cause repeatable
>compiler errors, always at exactly the same point in the build.

When I had bad kernel compiles due to bad RAM, the error didn't
always occur at the same place, and in fact sometimes it completed.

>One difference I noticed after my initial post is that the 7500 has
>the glibc-2.1.3-0j packages installed, while the G3 has 2.1.3-0b (as a
>reminder, the compilation works on the G3, not on the 7500).  Would
>this be a likely culprit?  Are the 2.1.3-0b packages even downloadable
>anymore?

In order, it could be, and I don't know.

>What other crucial packages (other than gcc, which is the same on both
>machines), are involved in compilation and could generate an internal
>compiler error?

Afraid I can't help there.  Just wanted to point out something that
has happened to me.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/