(You might want to read the p.s. before you get too deeply into the
body of this message...)

Hi y'all-

In my quest to get AFS running, I have pinpointed the current holdup
as being with ld.  The command that's causing problems is this:

/sbin/modload -v -d -o /usr/vice/etc/dkload/netbsd_afs -e afsmodload \
    -p /usr/vice/etc/rc.local.afs.2 /usr/vice/etc/dkload/libafs.o

the relevant portions of which (I think) are this:

modload -o /usr/vice/etc/dkload/netbsd_afs -e afsmodload \
    /usr/vice/etc/dkload/libafs.o

This line comes right from the AFS distribution I received, except
that I added a space between -e and afsmodload for readability.  This
change doesn't seem to effect the problem I'm having.

Modload calls ld thusly:

/sbin/modload -v -d -o /usr/vice/etc/dkload/netbsd_afs -e afsmodload \
     -p /usr/vice/etc/rc.local.afs.2 /usr/vice/etc/dkload/libafs.o

which then dies like so:

Segmentation fault - core dumped
modload: can't prelink `/usr/vice/etc/dkload/libafs.o' creating \
     `/usr/vice/etc/dkload/netbsd_afs'

It seems to me like there's a bug in ld.  I can't verify for sure that
my libafs.o is a valid .o file, but I think it ought to be, and ld
shouldn't dump core on it even if it isn't!  (right?)  If it makes a
difference, libafs.o is a mc68020 binary and I only have options
MC68030 turned on in my kernel config file...

Anyone have any input?  Thanks in advance!

-Jesse

Uhh... Doh!!  I may have found the problem.  The file libafs.o claims to be a 

libafs1_2.o.1.39: mc68020 executable not stripped

from a Linux/i386 box, but claims to be a 

libafs1_2.o.1.39: NetBSD/i386 object file not stripped

from my Mac running NetBSD.  This is the _exact same file_ ftped
directly over...  I don't know why neither os will claim the file
(each blames the other) but I thought this might be part of the
problem.  If libafs.o is indeed of i386 origin and not MacOS.  Still,
though, it shouldn't _crash_ the linker, should it?  You'd think ld
would return a "Bad object file" error or something in this case.