[ I'm CC'ing this to tech-toolchain because I think we should add the
  Elf vectors that we _can_ add to the a.out ports libbfds NOW before
  we switch to a libbfd-using linker, thus making our upgrate path
  a bit harder when we encounter the bug mentioned below.  --thorpej ]

hi folks...

I just added elf32-m68k support to the NetBSD/m68k bfd target.  This is
because I'm working on getting Elf working for NetBSD/m68k (something I've
been toying with for a while).

Unfortunately, this means that you will need to relink all of the programs
that use libbfd (src/gnu/usr.bin/{binutils/gdb}).  One would have hoped
that it would Just Work when the new shared library was installed, but
sadly, it does not because of what I consider to be bugs in the binutils[*].

Anyhow, build a new libbfd first, then build the new binutils and gdb,
then build the world after the next SUP scan.

Sorry for any inconvenience this might cause, but the world will eventually
be a better place because of it.

Let me know if you have any problems, and I'll try and help you out.

[*] The bug is that the binutils directly access libbfd's selected targets
vector, rather than calling libbfd functions (which don't exist, grr) to
access the vector.  This means that the size of selected vector symbol
changes, in this case growing by 4 bytes because 1 vector was added,
and ld.so issues a warning and does only the "expected" size.  In this
particular case, it means the array's terminationg NULL doesn't get copied
in, causing you to run off the end of the array, dereferencing other stuff
which causes a segv or bus error.  Sigh.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942