Well, whenever I run into something like this, the first thing I do is to
remove the offending file and then rerun make.  Perhaps the file got
corrupted somehow?  There're some bugs in both of the NetBSD/Mac68k SCSI
drivers that can result in corruption.

I occassionally get, for example, a "short read" whereby one byte in the
middle of a transfer gets dropped.  If this happens to be while reading a
library file during a ld (which, it seems, happens more than anything
else) you'll get strange things like "bad magic" for a module whose name
is missing the first character!  Unfortunately, things like libc tend to
stay around in the buffer cache for a while due to their frequent useage,
so the only way to force it to reread is to reboot or do something that
causes the entire mbuf cache to get cycled.  (On my 64MB system, the cache
is rather arge and takes a while to flush!)

On Mon, 18 Aug 1997, Mason Loring Bliss wrote:

> On 8/17/97 at 7:56 PM -0700, you wrote:
> 
> > As it turns out, 99% of problems building -current can be fixed by either
> > rebuilding config or rebuilding make ;-)  The rest can be solved by
> > resupping ;-)
> 
> Heh... Well... I'm using the latest tarred config right now, and from all
> appearances I've got a recent supped version of the kernel (common and
> mac68k) as of 4:00 AM today, and yet:
> 
> making sure the fpsp is up to date...
> ld -r -o fpsp.o copyright.o  netbsd.o  bindec.o  binstr.o  decbin.o  do_func.o
> gen_except.o  get_op.o  kernel_ex.o  res_func.o  round.o  sacos.o  sasin.o
> sata
> n.o  satanh.o  scosh.o  setox.o  sgetem.o  sint.o  slogn.o  slog2.o  smovecr.o
> srem_mod.o  scale.o  ssin.o  ssinh.o  stan.o  stanh.o  sto_res.o  stwotox.o
> tbl
> do.o  util.o  x_bsun.o  x_fline.o  x_operr.o  x_ovfl.o  x_snan.o  x_store.o
> x_u
> nfl.o  x_unimp.o  x_unsupp.o  bugfix.o
> ld: x_unimp.o: malformed input file (not rel or archive)
> *** Error code 1
> 
> Stop.
> *** Error code 1
> 
> Stop.
> 
> 
> 
> Does this suggest anything to anyone? Unfortunately, I compiled the beast
> in a 'screen' window, and I don't seem to be able to retrieve the bit where
> x_unimp.o was compiled, so I can't see if there were any errors there. I'm
> hoping someone else has seen and figured out this particular problem. If
> not, I'll try it again, making sure I keep a copy of my output next time so
> I can see exactly what happened with x_unimp.o to make it so unsocial.
> 
> Thanks in advance for the additional help! I feel like I've been flooding
> people with requests for help... All I can say is that once I've topped the
> hill, I'll start contributing code. I've already decided that I like NetBSD
> enough that it is going to be my primary operating system once my 68LC040
> is supported. (Or, once I get enough cash together to buy a real 68040. :)
> 
> Later...
> 
> --
>         Mason Loring Bliss    /\    mason@acheron.middleboro.ma.us
>       PGPKeyID: 0x25B3D5B5   /()\   awake ? sleep() : dream();
> <barbaric>YAWP!</barbaric>  /    \  http://genesis.tiac.net/~mason
> 
> 

-----------------------------------------------------------------------------
| Paul Goyette       | PGP Public Key fingerprint:  | E-mail addresses:     |
| Network Consultant |     0E 40 D2 FC 2A 13 74 A0  |  paul@whooppee.com    |
| and kernel hacker  |     E4 69 D5 BE 65 E4 56 C6  |  paul_goyette@ins.com |
-----------------------------------------------------------------------------