I've not had a successful build/snapshot complete since the 24th. Some of
that was the aforementioned disk space shortage, but a more pressing
problem has raised its ugly little head:

"sometimes" ld bus errors in md_relocate() while doing final linking of
binaries being built, including of itself. I imported a known-working ld
from another sun4m that is only slightly behind -current du jour, and it
dies too.

An example of what happens when I try to rebuild ld itself on the affected
system:

cc   -o ld ld.o symbol.o lib.o shlib.o warnings.o etc.o rrs.o xbits.o md.o
-lgnumalloc
cc: Internal compiler error: program ld got fatal signal 10
*** Error code 1

Stop.
root@atomic 74} !gdb
gdb /usr/bin/ld ld.core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.11 (sparc-netbsd), Copyright 1993 Free Software Foundation, Inc...
Core was generated by `ld'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libgnumalloc.so.0.0...done.
Reading symbols from /usr/lib/libc.so.12.17...done.
#0  0x114f8 in md_relocate (r=0x1fc00, relocation=85, addr=0xefffe63f "'",
    relocatable_output=0) at /usr/src/gnu/usr.bin/ld/ld/../arch/sparc/md.c:141
141             switch (RELOC_TARGET_SIZE(r)) {
(gdb) bt
#0  0x114f8 in md_relocate (r=0x1fc00, relocation=85, addr=0xefffe63f "'",
    relocatable_output=0) at /usr/src/gnu/usr.bin/ld/ld/../arch/sparc/md.c:141
#1  0x9454 in perform_relocation (
    data=0xefffe5f0 "$NetBSD: crt0.c,v 1.19 1997/10/09 12:29:37 lukem Exp $",
    data_size=2656, reloc=0x1fc00, nreloc=0, entry=0x1d000, dataseg=0)
    at ld.c:3027
#2  0x879c in copy_text (entry=0x1d000) at ld.c:2695
#3  0x4250 in each_full_file (function=0x8688 <copy_text>, arg=0x0) at ld.c:924
#4  0x85f0 in write_text () at ld.c:2655
#5  0x8180 in write_output () at ld.c:2554
#6  0x2f94 in main (argc=22, argv=0xeffff32c) at ld.c:400
(gdb)


Apparently, ld does not like the new version of crt0.o. The changes seem
innocuous enough:

===================================================================
RCS file: /cvsroot/src/lib/csu/sparc/crt0.c,v
retrieving revision 1.19
retrieving revision 1.18
diff -r1.19 -r1.18
1c1
< /*    $NetBSD: crt0.c,v 1.19 1997/10/09 12:29:37 lukem Exp $  */
---
> /*    $NetBSD: crt0.c,v 1.18 1996/12/27 21:44:59 pk Exp $     */
34d33
< #include <sys/cdefs.h>
36c35
< __RCSID("$NetBSD: crt0.c,v 1.19 1997/10/09 12:29:37 lukem Exp $");
---
> static char rcsid[] = "$NetBSD: crt0.c,v 1.18 1996/12/27 21:44:59 pk Exp $";


BTW, I'm running a kernel compiled today.

Comments, Luke?

	curious,

	Erik <fair@clock.org>